[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

[CobaltWolf]

6 hours ago, StickyScissors said:

Proposal #1.5: Swap between Apollo service module blocks 1 and 3. I have no idea what block 2 looks like, because google won't give me anything, but it must be very similar to block 1, so it can be ignored.

Example:

  Reveal hidden contents

Note that BIII, III+, IV and V are shown, but the only one i request would be the standard BIII. Seeing as how BIII+ and IV can most likely be made with the station parts, and BIV could be made with stock panels, they are extra unneeded work. For the engine, i assume just using the engine-swapping modue you have already created would work there, but i don't know what variant BIII and beyond uses. Probably just another variant that could faked with engines already made. the shuttle maneuvering engines, perhaps are a good option due to their size similarity with BIII

The Apollo Block 1 had a built in heater was the original-ish design, from before Lunar Rendevous was firmly selected. It had no docking port on top, and had the old command module that (among other things) was very shoddily made, resulting in the Apollo 1 fire. Their service modules are pretty much the same. When you think of Apollo, you think of Block 2. That's the one that went to the moon.

[RedParadize]

@Shadowmage Ok, I stoped playing Kerbal a few weeks and I trough well I was just gonna looks whats new with SSTU and NFT/FFT. Your stations part are amazing. Its insane, I can't believe I have played that long without it.

 

4 hours ago, Jimbodiah said:

Mage, is it possible to make the center part of the large hab tori the same as the H (with two tunnels and two support beams)?

I agree. In fact I would put support beams on all of them. If I can suggest, It would be nice to have exagonal beams around tunnels. Or even better,  just flat vertical beam, but more of them. Like one on each side of tunnel and few more of them depending of the size of the torus. It kinda make sense from a structural standpoint would be much more compact when folded. Technically cable would do sice the pressure inside the torrus would be enough to maintain most of the structural integrity. But that would not be nice or believable. 

Edited August 5, 2016 by RedParadize

[tater]

 

Using @cxg2827's excellent parts as an IVA analog again (I should have rotated them slightly so the floors were level)... The small torus has a fair bit of room. They would actually fit entirely inside the torus, they are stuck on the skin, so the torus looking smaller is perspective only.

The KHM-3-1 holds 2 crew, so there are 16 slots there. Each kerbal could get one as a room, and there is still room for a lab and a common area for meals. For reference, the stock MPL part is about 1.5X the length of those pods. So there is room for a lab, plus 6.5 of these habs. So your crew rating of 5 is very generous to them, they each get a room of their own, plus 1.5 of those as a common area, plus a lab.

You could have a crew of 6, and have 5 of these hab volumes available for common space, equipment/supplies, and a lab. I lean towards that as a number.

Edited December 19, 2017 by tater

[Pappystein]

First, I know this is an EARLY release of the station parts but I wanted to share my experience with a few of the parts.

 The Welding Docking ports are neat as well as long needed, but have minor issues.   If there is no docking port autopilot, the docking ship can drift away while you switch perspective to the target, activate it's clamp then switch back.    If the port should be armed BEFORE attempting to dock, then maybe should change the text to read "Ready to Dock" instead of "Armed."    Since Armed implies the explosion (Weld) is NEXT.   If nothing else, maybe a "Bug check" to make certain the ports are lined up and connected before performing the weld?

As a docking ship, when I target the docking port it asks me to re-name ports and until I am very close (less than 500m as the crow flies,) I am unable to actually select the docking port and then declare it my target until I am closer than 500m.   I had a Stock docking port on the station and could select it as my target from further away.

I built a Tinkertoy station with predominantly SSTU, FASA and Stock parts.   Even with the miss-aligned welds (my two Solar panel spars array is bent and twisted slightly out of alignment,)   this is by far the best, most functional station I have been able to build.   And that is with a patch work look due to the no textures.  

I have not launched any of the pre-built habitats yet but the DOS docking modules work great given the caveat above.   Even with the bent weld the two Solar Panel spars I joined with the welding docking port do not collide with each other and are as rigid as anything can hope to be in a game where wobbliness is a requirement.   They even stayed rigid under asymetrical thrust.   Something other parts were unable to withstand.

 

 

Edited August 8, 2016 by Pappystein
clarification

[Shadowmage]

On Friday, August 05, 2016 at 1:00 AM, StickyScissors said:

@Shadowmage As you have recognized, my brand new GPU has gone poo poo, and while i return it back to Amazon and wait for a refund to buy a replacement, i have been thinking a lot more than usual, and i have come up with some ideas that may or may not have been brought up before:

Proposal #1: An option to swap Soyuz's service module between the regular, LEO/LKO variant with the extended 7K-LOK version, which was to be used for Lunar excursions. And possibly make it a wee bit more powerful. Even around the Mun it's difficult to use.

To go along with the swapping of service modules, it would also be cool to have the have the option to swap the current black/dark gray color of the entire spacecraft with the green of older variants. I'd make the texture myself but...i don't know how. The files can't be modified in GIMP without a plugin (of which doesn't work anyways), and i don't have photoshop

Example, ASTP mission: 

  Reveal hidden contents

Proposal #1.5: Swap between Apollo service module blocks 1 and 3. I have no idea what block 2 looks like, because google won't give me anything, but it must be very similar to block 1, so it can be ignored. Block 2 was used for the actual Moon missions, Block 1 was Apollo 1 and previous, so Block -1- can be ignored.

Example:

  Reveal hidden contents

Note that BIII, III+, IV and V are shown, but the only one i request would be the standard BIII. Seeing as how BIII+ and V can most likely be made with the station parts, and BIV could be made with stock panels, they are extra unneeded work. For the engine, i assume just using the engine-swapping modue you have already created would work there, but i don't know what variant BIII and beyond uses. Probably just another variant that could faked with engines already made. the shuttle maneuvering engines, perhaps are a good option due to their size similarity with BIII

 

Proposal #2: Modular/procedural fairings, beyond the fiddly ones that stock implements (i'm having serious trouble closing them at the point sometimes ).

I'm thinking about a fairing base, with adjustable bottom/top diameters, height (via model swapping or just stretching), the middle piece with adjustable length, and the top/cone bit that could be swapped out for others. So as not to inflate the part count of the vessel, maybe just have the fairing as one big part that splits into 2 when staged (rather than having 2 separate halves built with individual pieces) to begin with? That's how stock fairings seems to do it, and that works ok most of the time.

Examples of fairings that could be made, Soyuz(can you tell i really like Souyz ❤️): 

Titan fairings. The only difference between these would be the base shape (configurable, ofc), while the panels would just be a different diameter due to the base top being scaled differently. I hope you catch my drift, i'm really sleepy: 

Proposal #3: A way to align ports to make multi-port docking easier. Maybe just a single long, skinny docking port that reaches from one end of the tank to the other (down the side) of some sort so i can dock tanks side-by-side. This would prevent the process of: align, dock, realize i screwed up, undock, repeat until i get it right. It would make docking things like Project Argosy type ships together a lot less tedious.

Example: 

  Reveal hidden contents

 

Ideas i had that won't work, or that i suspect you wouldn't bother with

• Being able to swap the current lander can out with the LK lander.

Why it won't work: It would mean swapping IVA's which isn't possible, if i'm reading previous posts correctly.

• MAKS Spaceplane:

Why it won't happen: Waaay too many non-modular parts. IVA, carrier craft to launch from, fuel tank, wheels. 

• Modular command capsule.

Why it won't work: IVA swapping. Nope, NEEEXT!

• Lots of other non-modular stuff...ehh, you get the point. I'm tired, and i'm going to sleep.

Additional service modules -- sort of planned, but mostly cancelled.  There was no way that I could find to make them modular enough; I'd essentially just be making a ton of single stand-alone parts... which isn't worth it to me just for service modules -- there is not enough room for modularity in order to make each service module useful for multiple purposes.

Fairings -- I will not be doing any sort of full procedural fairing, mostly due to GUI restrictions.  The stock mouse-driven system sucks, so I would not be using that system, and I have no clue how I'd make a GUI that would be useful for procedural fairings.  The closest I may come to this would be some pre-built resizable fairing models; so like 3 different lengths with the width set through sliders/standard GUI controls.  But I have no desire to do this anytime soon as the stock fairings do their job just fine.

Multi-docking alignment -- feel free to patch in the stock angle restrictions if you want.  I don't want or need them (as I use MJ to hold alignment, and I dock everything manually).  If there is enough desire I may release a patch to do so, but I don't think it will be the default behavior.

 

On Friday, August 05, 2016 at 7:31 AM, Jimbodiah said:

Mage, is it possible to make the center part of the large hab tori the same as the H (with two tunnels and two support beams)?

Sure; none of those are 'done' yet.  Not sure the G hab will even stay with what it has, mostly used it to test if the animation for those types of supports would work.  Not even sure if the G torus will even be inflatable in the end (its original design goal was for a rigid non-inflatable torus for the largest two sizes; to be built in orbit by EPL).

 

 

13 hours ago, Pappystein said:

First, I know this is an EARLY release of the station parts but I wanted to share my experience with a few of the parts.

 The Welding Docking ports are neat as well as long needed, but have minor issues.   If there is no docking port autopilot, the docking ship can drift away while you switch perspective to the target, activate it's clamp then switch back.    If the port should be armed BEFORE attempting to dock, then maybe should change the text to read "Ready to Dock" instead of "Armed."    Since Armed implies the explosion (Weld) is NEXT.   If nothing else, maybe a "Bug check" to make certain the ports are lined up and connected before performing the weld?

As a docking ship, when I target the docking port it asks me to re-name ports and until I am very close (less than 500m as the crow flies,) I am unable to actually select the docking port and then declare it my target until I am closer than 500m.   I had a Stock docking port on the station and could select it as my target from further away.

I built a Tinkertoy station with predominantly SSTU, FASA and Stock parts.   Even with the miss-aligned welds (my two Solar panel spars array is bent and twisted slightly out of alignment,)   this is by far the best, most functional station I have been able to build.   And that is with a patch work look due to the no textures.  

I have not launched any of the pre-built habitats yet but the DOS docking modules work great given the caveat above.   Even with the bent weld the two Solar Panel spars I joined with the welding docking port do not collide with each other and are as rigid as anything can hope to be in a game where wobbliness is a requirement.   They even stayed rigid under asymetrical thrust.   Something other parts were unable to withstand.

 

 

I've had no problem with the WDP when switching vessels; the magnetics should still kick in quite a ways out and hold the vessels together long enough to switch between them to arm/retract the ports... or do what I do and start with one already retracted/armed.

I'll take a look at it though; there is a chance that the magnetics range is not large enough for when the ports are rescaled (I currently do not adjust the ranges with rescales, it uses 0.5m magnetic range for all sizes).

[Pappystein]

3 hours ago, Shadowmage said:

I've had no problem with the WDP when switching vessels; the magnetics should still kick in quite a ways out and hold the vessels together long enough to switch between them to arm/retract the ports... or do what I do and start with one already retracted/armed.

I'll take a look at it though; there is a chance that the magnetics range is not large enough for when the ports are rescaled (I currently do not adjust the ranges with rescales, it uses 0.5m magnetic range for all sizes).

I think in part the issue is that it took a lot of time (probably 20 or 30 seconds for the parts that welded correctly) to "meld together."   Since I was using MechJeb's docking assistant that may have had a part to play in the issue.  Port size was "Stock" 2.5m

 

Since my first post I have been having an issue with UNDOCKING things that were on the station the last time I launched.   I have to basically scrap my whole station due to the SSTU docking ports not undocking.    I placed one module Front to back which is blocking off ports (Angular obstruction)    I have Hyperedit but have not used it to Oribit any of the items on the station.  I DID have to use it to land one of my tugs that I used at the Station.   It was in danger of crashing into KSP (Failed chute no power to maneuver.)  Is this Hyperedit shenanigans?

Edited August 8, 2016 by Pappystein
Clarification

[tater]

Dunno, I have a love-hate relationship with HE. I keep it around for certain testing applications, and sometimes to replace stuff wrecked by the kraken, but it has its own kraken within, I think  

[RedParadize]

6 hours ago, Shadowmage said:

Sure; none of those are 'done' yet.  Not sure the G hab will even stay with what it has, mostly used it to test if the animation for those types of supports would work.  Not even sure if the G torus will even be inflatable in the end (its original design goal was for a rigid non-inflatable torus for the largest two sizes; to be built in orbit by EPL).

Oh, thats sound great! What about a "small" O'Neill cylinder? 

Do you think that it would be possible to have other rigid centrifuge? It would be great to have a habitat on a arms plus a counterweight on the other side. Or something like the Clark-A. These design could be done almost entirely with reused mesh and IVA.

[StickyScissors]

10 hours ago, Shadowmage said:

Fairings -- I will not be doing any sort of full procedural fairing, mostly due to GUI restrictions.  The stock mouse-driven system sucks, so I would not be using that system, and I have no clue how I'd make a GUI that would be useful for procedural fairings.  The closest I may come to this would be some pre-built resizable fairing models; so like 3 different lengths with the width set through sliders/standard GUI controls.  But I have no desire to do this anytime soon as the stock fairings do their job just fine.

Hmm, ok, understandable objections. Although, on the topic of fairings, i have had another idea.

Is it possible to have the option of fairings that stem from the top of a fuel tank? I have some plans in place of launching (and later, expanding) a Skylab-alike station (half of it a fuel tank not shrouded, but the other bit is shrouded, starting from the top of the tank) and would prefer not to have extra parts (fairing base) loitering around when this thing gets big. Custom fairing panels not needed

Spoiler

 

[Shadowmage]

10 hours ago, StickyScissors said:

Hmm, ok, understandable objections. Although, on the topic of fairings, i have had another idea.

Is it possible to have the option of fairings that stem from the top of a fuel tank? I have some plans in place of launching (and later, expanding) a Skylab-alike station (half of it a fuel tank not shrouded, but the other bit is shrouded, starting from the top of the tank) and would prefer not to have extra parts (fairing base) loitering around when this thing gets big. Custom fairing panels not needed

  Reveal hidden contents

 

Possible, sure; see the MUS tanks... they have fairings at both ends.  Something I want to take the time to implement?  Not really; I cannot think of any good uses for it, nor is there any good method to determine when the fairing should be enabled/not enabled, nor any way to tell how tall the fairing should be.  Lower fairings are easy; they just snap to the bottom node of the part below;  that doesn't seem to be a good way to do it for the top fairings.  (MUS tanks use a special top-cap which tells me how tall the fairing needs to be, which is why they can be used there without these problems)

What is the intended use-case for these?  I really can't think of any time you would want upper fairings unless you are trying to use them as some sort of procedural adapter?

 

In regards to your earlier request for more SC-A textures;  you can use the GIMP - .dds plugin to open them up; however they are spec-masked and there is no easy way to remove the spec mask/alpha channel that I've found.  However, if you are truly interested, let me know and I can send you the original GIMP project files (4 in total, one for each part).

I have nothing against more textures for it.... I'm just not making textures at the moment / for the foreeseable future.  Thankfully it sounds like the wheel replacement system may finally be going somewhere/making progress... so I may be able to return to concentrating on SSTU before too much longer.

In other news I spent quite a bit of time yesterday working through how USI-LS functions with all of its new... functions.  After a bit of reading it seems... casual enough... Its a fairly simple system even with the additions of hab-time.

Put together some preliminary numbers for hab time, supplies qty, and recyclers setups for the DOS and COS modules.  Going to require quite a bit of patching to get the LS stuff in-place, as every single part is going to need its mass and containers adjusted in order to accommodate the mass and volume of the supplies (which do seem ridiculous; 16kg/day, for a kerbal? I may go through 2-3kg/day including water.... 16 seems... way too much).

On that note -- how many crew should a basic DOS station support?  It would be 6 modules with total crew capacity of 18 (3 seats per module), but I feel like the life-support should be geared for much lower optimal capacity (3-6 crew, 12 at the very high end).

[Shadowmage]

17 hours ago, Pappystein said:

I think in part the issue is that it took a lot of time (probably 20 or 30 seconds for the parts that welded correctly) to "meld together."   Since I was using MechJeb's docking assistant that may have had a part to play in the issue.  Port size was "Stock" 2.5m

 

Since my first post I have been having an issue with UNDOCKING things that were on the station the last time I launched.   I have to basically scrap my whole station due to the SSTU docking ports not undocking.    I placed one module Front to back which is blocking off ports (Angular obstruction)    I have Hyperedit but have not used it to Oribit any of the items on the station.  I DID have to use it to land one of my tugs that I used at the Station.   It was in danger of crashing into KSP (Failed chute no power to maneuver.)  Is this Hyperedit shenanigans?

Please let me know if you can find how to duplicate the lack of undocking option; that was one of the major problems I was afraid I'de run into with those docking ports.  Which specific parts were involved, and docked together in what order?  Did they include optional docking ports at both ends, or just one end?  Did you toggle the docking port options a few times before launching, or just use whatever the default was?  (trying to eliminate as many variables as possible... and there are a ton of them in this case).

Might also be beneficial if you could upload a save file that has that problem occurring in it... I may be able to take a look at the persistence data to see what is up with the ports/why they have no undock option.

Yes, HE could cause those sorts of problems, but not by just being installed; the vessels need to have their orbit adjusted by HE in order for it to effect them.

[tater]

Current consumables are something like 1.84kg/day according to NASA for humans (that's only stuff that needs to be added to the system, since water is largely recycled, and much of the air is scrubbed). 

Looks like the USI-LS parts (including tank dry mass) are 0.2kg/supply unit. So 3.24 kg/day. That's not far off that NASA value when you consider that 1.84 number doesn't include anything recycled, but "supplies" don't consider recycling, so with the various modifiers, it likely comes back into line.

The USI-LS value is 16.2 supplies per day, but they don't mass 1kg/supply, they mass more like 0.2kg/supply.

Edited August 9, 2016 by tater

[Shadowmage]

6 minutes ago, tater said:

16kg/day is ridiculous. 

Current consumables are something like 1.84kg/day according to NASA for humans (that's only stuff that needs to be added to the system, since water is largely recycled, and much of the air is scrubbed). 

LoL, Indeed.  That 16.2kg/day... is for a 6-hour Kerbin-day... which is 2.7kg/hour.

Seems like a 90% recycler is needed to bring that rate down to anything reasonable, and is perhaps what was intended.  I could maybe see 16kg/day if it included all waste-water and atmosphere/gas uses prior to any recylcers/scrubbers/purifiers.

 

[JoseEduardo]

1 hour ago, Shadowmage said:

Possible, sure; see the MUS tanks... they have fairings at both ends.  Something I want to take the time to implement?  Not really; I cannot think of any good uses for it, nor is there any good method to determine when the fairing should be enabled/not enabled, nor any way to tell how tall the fairing should be.  Lower fairings are easy; they just snap to the bottom node of the part below;  that doesn't seem to be a good way to do it for the top fairings.  (MUS tanks use a special top-cap which tells me how tall the fairing needs to be, which is why they can be used there without these problems)

What is the intended use-case for these?  I really can't think of any time you would want upper fairings unless you are trying to use them as some sort of procedural adapter?

well, if he isn't going to modify any size of the fairings in the future perhaps he could make one with several entries of the SSTU fairing module, like the Orion SM does?

should be fairly easy once one looks at the .cfg of the SM and see what needs to be changed

to be fair now that I'm thinking this through I could also try something similar for some customized stations I'm planning... I'm thinking about 8.4m and 6.6m (in RW scale, but for stock they are going to be around 5.375m and 4.25m, for personal use of course) stations, so I could do some of these myself for said modules and see if it works... if it does then I might leave an example for those interested

the only thing that might go wrong with this is the top of the fairing, I'm not sure if setting it to 0 will actually protect it through the atmosphere or even work in the first place.... good thing I have RN's Skylab to try first 

[Shadowmage]

13 minutes ago, JoseEduardo said:

well, if he isn't going to modify any size of the fairings in the future perhaps he could make one with several entries of the SSTU fairing module, like the Orion SM does?

should be fairly easy once one looks at the .cfg of the SM and see what needs to be changed

to be fair now that I'm thinking this through I could also try something similar for some customized stations I'm planning... I'm thinking about 8.4m and 6.6m (in RW scale, but for stock they are going to be around 5.375m and 4.25m, for personal use of course) stations, so I could do some of these myself for said modules and see if it works... if it does then I might leave an example for those interested

the only thing that might go wrong with this is the top of the fairing, I'm not sure if setting it to 0 will actually protect it through the atmosphere or even work in the first place.... good thing I have RN's Skylab to try first 

Sadly the fairings won't work on the top of the tanks right out of the box; they would need special back-end plugin support (to setup their top/bottom positions and diameter when the tank length or diameter changes).  Well... you could get them working for a single length and diameter of tank... but without the plugin side dynamic repositioning/resizing, that is the best you could get.

And I cannot think of a way to do the plugin side repositioning; as I stated earlier... how tall should they be?  What should they snap to?  When would they be enabled/disabled?  So, its more like... its possible in theory, but impossible in practice, or at least in a practical implementation.

[tater]

@Shadowmage, the supply part masses divided by the supplies give a lower number. The only 16 I see is 16.2 supplies/day, and a supply pack with 100 supplies is 0.02 mass. ISS has a 90%recovery rate on stuff like water, right? So that's likely the intent, anyway. Throw you in a hermetically sealed pod with supplies and spare throw-away CO₂ scrubbers, and you need a lot of stuff with you. As you recycle elements of the supplies, that drops a lot.

The larger tori would have pretty much all the recycling possible. I posted in the USILS thread that I thought that gravity should really be a habitation multiplier generally. Why put a base on a world? Because gravity. I think that's true in RL, though there is some cutoff below which it likely doesn't help much (they have actually discussed centrifuges within lunar bases, since lunar gravity might not be enough to maintain human physiology). If you used the mass of the tori (as suggested) that sort of works, the large one has a multiplier of 160 something,right  

I'd assume that a lot of the space within would be LS "tankage," not fuel, honestly. That and "mulch" in the USILS world. FWIW, I have read that some long-duration mission concepts include storing human waste as radiation shielding. In a torus, waste would naturally centrifuge to the outside wall (imagine a waste take there), whereupon any water could be recycled, leaving sludge.

Edited August 9, 2016 by tater

[JoseEduardo]

3 minutes ago, Shadowmage said:

Sadly the fairings won't work on the top of the tanks right out of the box; they would need special back-end plugin support (to setup their top/bottom positions and diameter when the tank length or diameter changes).  Well... you could get them working for a single length and diameter of tank... but without the plugin side dynamic repositioning/resizing, that is the best you could get.

And I cannot think of a way to do the plugin side repositioning; as I stated earlier... how tall should they be?  What should they snap to?  When would they be enabled/disabled?  So, its more like... its possible in theory, but impossible in practice, or at least in a practical implementation.

that's what I was talking, they wouldn't be dynamic, they would instead be set for a specific use, like being set for Skylab, and wouldn't be used anywhere else nor the lengths would change without changing them in the .cfg, pretty much what happens on the Orion SM adapter, except that the adapter does change in the bottom-most end, and in this scenario it wouldn't at all, it would be intended for a specific use only at a specific scale

that's the best solution I can see using the existing code

(and in the end there is already the procedural fairings mod for most of the payloads, and some packs include new fairing designs. I even made a N1 fairing myself for the PF mod)

[Shadowmage]

3 minutes ago, tater said:

@Shadowmage, the supply part masses divided by the supplies give a lower number. The only 16 I see is 16.2 supplies/day, and a supply pack with 100 supplies is 0.02 mass. ISS has a 90%recovery rate on stuff like water, right? So that's likely the intent, anyway. Throw you in a hermetically sealed pod with supplies and spare throw-away CO₂ scrubbers, and you need a lot of stuff with you. As you recycle elements of the supplies, that drops a lot.

The larger tori would have pretty much all the recycling possible. I posted in the USILS thread that I thought that gravity should really be a habitation multiplier generally. Why put a base on a world? Because gravity. I think that's true in RL, though there is some cutoff below which it likely doesn't help much (they have actually discussed centrifuges within lunar bases, since lunar gravity might not be enough to maintain human physiology). If you used the mass of the tori (as suggested) that sort of works, the large one has a multiplier of 160 something,right  

I'd assume that a lot of the space within would be LS "tankage," not fuel, honestly. That and "mulch" in the USILS world. FWIW, I have read that some long-duration mission concepts include storing human waste as radiation shielding. In a torus, waste would naturally centrifuge to the outside wall (imagine a waste take there), whereupon any water could be recycled, leaving sludge.

My values for supplies density/mass comes from the resource definition:

RESOURCE_DEFINITION
{
   name = Supplies
   density = 0.001
   flowMode = ALL_VESSEL
   transfer = PUMP
   unitCost = 2.5
   isTweakable = true
	volume = 1
}

Supplies have a density of 0.001 (1kg) per unit, and a volume of 1-liter per unit.  1000u (1m^3) of supplies would weight 1 ton, and the 100u supplies pack could weigh no less than 0.100t (100kg) + dry mass (maybe that 0.02 is the dry mass?).

Thus, 16.2 units of supplies per day = 16.2kg of supplies per day (or 16.2 liters if going by volume).

So, basically, yes; most of the station parts will probably be coming with 90% recyclers; otherwise the mass of the supplies for even a few months for the supported crew capacity would outweigh the entire mass of the modules.

[tater]

Ah, I simply looked at the supply parts that came with supplies. So the mass I am talking about is the dry mass alone of that tank? Wow.

According to NASA, people need ~5kg of water, food, and O₂ per day.It's also important to note that the first 15 days in USILS are free with every crewed part. For many realistic mission durations, that significantly reduces LS mass costs.

[tater]

BTW, I just remembered that in testing with the welding feature last night, I put a torus ha to one of the new station parts---I think it was the lab with the built-in solar arrays, and the flat top, I'll have to check later---and there was a tiny gap after welding. I think I put torus, new SSTU probe core ring, then weld port, and the lab part simply had the welding port on. So it welded the probe ring to the lab, technically. The gap is less than the probe ring height as I recall.

Edited August 9, 2016 by tater

[Shadowmage]

1 hour ago, tater said:

BTW, I just remembered that in testing with the welding feature last night, I put a torus ha to one of the new station parts---I think it was the lab with the built-in solar arrays, and the flat top, I'll have to check later---and there was a tiny gap after welding. I think I put torus, new SSTU probe core ring, then weld port, and the lab part simply had the welding port on. So it welded the probe ring to the lab, technically. The gap is less than the probe ring height as I recall.

Interesting; sounds like something has some mis-placed nodes or mis-specified model height... there certainly shouldn't be any gaps between my parts (stock parts are a different story with their inconsistent node placement).  Will add this to the list of things to investigate.

So.. the problematic parts in your case were the DOS-LAB and the new procedural probe core?

[tater]

Sorry I cannot remember the part names well... let me check. 

Hab-F has a PPC on it, connected to a DOS-TKS (sorry, thought it was a lab).

Oddly, the gap is between the adaptor on the torus, and the PPC. I'm pretty sure I put the probe core on the torus, I was unsure if I was going to use a little tug I built to push it or not when I first built it, and the TKS didn't need it.

Edited August 9, 2016 by tater

[Domfluff]

ISS recyclers were intended to be 90%, but in practice I believe they achieve 75% - which is possibly where the 16.2kg comes from, since 1/4 of that is less than the 5kg NASA figure. Let alone that this represents 16.2 kg per six-hour kerbal day.

But... that doesn't make a lot of sense to me either, since that 5kg figure is before recycling. You could also make the case that Kerbals should halve that, but that's probably not a great idea.

The USI-LS greenhouses are probably overpowered, since they reduce the required mass (as fertilizer) to very low levels.

It's notable that Roverdude is doing a large scale USI-LS/UKS rebalance for the 1.2 release, so it's very possible that his numbers will change again.

All of the above is configurable of course, but it's probably sensible to work around the standard USI-LS settings.

One thing that had become pretty clear to me is that he's been balancing this with the stock game in mind, and doing a reasonably good job of it, at least as far as cis-minmus space is concerned. LKO and the Mun are more than achievable without additional life support, but Minmus requires some extra supplies and possibly recyclers.

**

I think I'd be fine with 90% recyclers, at least for the moment. Design for effect, the actual utility is more important here.

The real problem I've had in designing plausible vehicles is the problem with hab multipliers, which make little sense to me. The idea is that working space (e.g., labs) give you some available space, hab modules give more more room to move (bonus kerbalmonths) and multipliers are supposed to be parts which give benefits throughout the whole ship. To give a far-future (slightly silly) example, a cinema or pub would give you a bonus throughout, not just for that module.

For a less far-future example, I think the toruses are more than reasonable to use as hab modifiers. Crews can rotate through the ship, so having work time spent in-gravity during transit is of great overall benefit to the crew. What values are given here are something quite different though.

Thinking in terms of actual game effect, I don't think you should *need* artificial gravity for a Duna mission. It would be nice, and might be a really good idea, but I think you should be able to get by without. This is also a good reason to have torus parts above hab parts on the CTT, so you can slum it in a low tech manner.

Duna transit is less than 300 days, so that's a reasonable figure to aim at for a Deep Space Habitat-like vehicle (i.e., ISS Lab module, ISS docking nod, ISS hab/MPLM module + propulsion bus, Orion and MMSEV). Architecture of this manner could keep a transit vehicle in-orbit and land the crew to an unmanned and previously deployed surface hab.

Anything beyond Duna should probably require artificial gravity. Checking out the Outer Planets mod, the extremes of the solar system (Neidon and Plock) are something like 23 and 35+ years to transit for a minimum energy transfer one way. Clearly then, a long term space habitat needs to end up with hab time approaching 50-100 years. That might be with a minimum crew (probably 4 or 6, since 2x Scientists, 1x Pilot, 1x Engineer seems sensible as crew minimum in most cases in KSP, but there are arguments for more especially with mission involving ISRU or other base parts. If I recall correctly, UKS does model "unhappiness" in the form of inefficiency for fewer than five kerbals at a Kolony, which may or may not be a consideration).

So, just throwing some arbitrary numbers out for the extreme end of things:

30 man torus for a 6 crew long (really long) duration mission would have:

(30 + Bonus Kerbal months) * Multiplier / Crew

Without bonuses, hab time is 150 days per crew member.

Assuming a bonus of 200 kerbal months (one KM per seat means this is +170) and a crew of six, that's:

30 + 170 * Multiplier / 6

Using a Multiplier of 30 and bonus of 200 Kerbalmonths here would allow for the largest torus to support hab time for six crew for about 70 years. That seems reasonable to me as a top-end "permanent" habitat, and is within reason for an interstellar flight (therefore a decent practical endgame limit for KSP). Certainly fine for pootling around the solar system.

[StickyScissors]

15 hours ago, Shadowmage said:

In regards to your earlier request for more SC-A textures;  you can use the GIMP - .dds plugin to open them up; however they are spec-masked and there is no easy way to remove the spec mask/alpha channel that I've found.  However, if you are truly interested, let me know and I can send you the original GIMP project files (4 in total, one for each part).

Thankfully it sounds like the wheel replacement system may finally be going somewhere/making progress... so I may be able to return to concentrating on SSTU before too much longer.

As it turns out, i actually am interested in them. me want.  I can make patches and i can get bored and ^remake stuff like this: 

Spoiler

But part textures with detail are something i've never really tried

Also, yay! working-ish wheels^{(and landy legs)}! My Mun colony ideas can't get anywhere other than paper without proper integrated wheels and legs.

 

Edit: Probably not something you'd be interested in working on, but how possible would it be to have custom text written down the side of a fuel tank? All the decal mods aren't updated and probably never will be. If not, am i correct in assuming just duplicating a tank texture and putting text on it would work out without the text stretching? It's hard to test things without a GPU ヽ(`Д´)ﾉ︵ ┻━┻

Edited August 10, 2016 by StickyScissors

[tater]

@Domfluff makes good points. I took this up in the USILS thread when it first came up, largely because the suggested hab multiplier is the mass for a part like the cupola. You could make a part with a single window (thick, leaded glass) and the entire thing is made out of lead, and that sucker multiplies habitation by its mass. Crew of 30, and 1 really overbuilt window can do what you like... how about a 10-ton porthole! 10X hab multiplier! Or, you know, spam cupolas.

If the large torus used its mass as a hab multiplier, lol. Yeah, move the wife and kids and settle down up there