Jump to content

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


Shadowmage

Recommended Posts

USI Life Support is pretty broken at the moment, and what I've seen from their UKS resources, it's a pretty complex loop which can not be used for anything else but UKS itself. Never saw the point of it all.

EPL and CRP would cover most of the resources I think. Anything else we could probably patch/hack later.

 

Link to comment
Share on other sites

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.30-pre1

New H-1 geometry (and full cluster layout/mount configs)(texture WIP), new Modular-Heatshield part (WIP; currently only resizable/change type, actual modularity function yet-to-come), and a few enhancements / updates to the engine-cluster module and data.  See the link for full change log and download links.

Link to comment
Share on other sites

Even in a scaled up system, the new heat shield part on a CMX survives reentry with just a medium with 266, vs the CM's own 450 that blows up pretty quickly. I assume the procedural is using the new technique, but not the capsules?

Link to comment
Share on other sites

9 hours ago, tater said:

Even in a scaled up system, the new heat shield part on a CMX survives reentry with just a medium with 266, vs the CM's own 450 that blows up pretty quickly. I assume the procedural is using the new technique, but not the capsules?

They are using the same heat-shield module, though with a slightly different setup.

Mostly it comes down to that I certified the parts to work under specific conditions, but probably need to do a bit more fine-tuning to reduce their over-capacity handling a bit.  Could also come down to the rig I was using to test them (6 shields at a time) -- was a beast that did -not- like to slow down very well, so it experienced a lot higher heat load than would normally be experienced under those conditions.

What I really need is more people testing these things with stock heating, that way I can get he balance finished, and then I can help you figure out the rescale stuff for system-scale mods.

Link to comment
Share on other sites

1 minute ago, tater said:

I will make a stock copy to test for you.

I wouldn't worry yourself about it too much -- unless you truly want to help and don't mind spending a few minutes testing and balancing things.  In which case, feel free to test them out :)  If you felt like playing with the 'balance' on them, you can alter (or add) the fluxMult parameter to the SSTUHeatShield module (default = 1; increase it to increase heat-load-capacity of the shield, decrease it to lower the heat-load capacity).

@PART[SSTU-SC-GEN-MHS]
{
    @MODULE[SSTUHeatShield]
    {
        %fluxMult = 1
    }
    @MODULE[SSTUModularHeatShield]
    {
        @SHIELDTYPE,*[*]
        {
            %ablationMult = 1
        }
    }
}

Drop that patch into a .cfg file somewhere in your GameData directory, and then alter the fluxMult value to adjust it for different heat-loads.   After heat-loading has been balanced, you can adjust the ablationMult if you find yourself running out of ablator too early or have too much ablator.  Lower = use more ablator, higher = use less ablator (it is a multiplier to the efficiency of each unit of ablator resource).  (Patch untested, written off the top of my head... but it -should- work.. or looks like it should work at least :) )

That same patch could/would be used for solar-system rescales (though I'll likely fix the ablationMult bit to be a single-line patch in the SSTUHeatShield module, rather than fixing it on a per-shield type basis).  For larger systems, you would use larger values for both flux and ablation multipliers.

 

What I would -really- like to do for the heat-shields, is derive a formula that could be used to balance them for specific scenarios.  But I have no idea how stock caclulates the heat load, and thus now way to derive such a formula.

Its something like heatLoadFlux = (extTemp - skinTemp) * exposedArea   -- but not exactly; and therein lies the problem -- there appear to be several other coefficients at play that I'm unfamiliar with.  I've sucessfully negated the *exposedArea part of the equation (used for the MHS parts to make them perform the same regardless of size), but cannot fathom how they are deriving the temperature input; especially as it relates to speed and atmospheric density (and I think each planet has a specific heating multiplier as well, to account for different gas types perhaps?).

Link to comment
Share on other sites

17 hours ago, tater said:

RoverDude has said he's looking at his own EPL-type functionality at some point, FWIW.

That would be nice -- would like to support (by default/as-shipped) a single production chain.  I consider the whole 'manufacture stuff in space' to be... well.. the next logical step for construction of large interplanetary craft, and even larger space stations; base additions, etc.  Its just a nice feature to have.  So I'll be supporting one or another of these mods.

And as I'll likely already be supporting the USI stuff, would be wonderful if he had a fully mod-contained production chain, without external dependencies and all the hacking that has been done to make it work with EPL.

Nothing against EPL's resource chain; just not integrated enough into other mods, and a bit simplified for my liking (contrast that to what I've seen of the recent MKS stuff, which appears to be over-complicating it a bit).

 

 

17 hours ago, Jimbodiah said:

USI Life Support is pretty broken at the moment, and what I've seen from their UKS resources, it's a pretty complex loop which can not be used for anything else but UKS itself. Never saw the point of it all.

EPL and CRP would cover most of the resources I think. Anything else we could probably patch/hack later.

 

Sadly you are correct (as far as the loop / usability with other mods) -- I'm unaware of any other mods that interact with the USI-LS stuff on a low-level.  Thankfully it comes with most bits you would need (or are available in MKS) -- recyclers, purifiers, converters, generators.

Can't speak as to its broken-ness or not... been probably about 6mo since I've played with it at all.  I also know RoverDude has added a bunch of 'habitation' stuff to USI-LS recently... and I have no idea how all of that plays out (but is a good excuse for some habitation-centric station/base parts :) ).

Link to comment
Share on other sites

More habs = longer hab period, but still limited (no way to prolong without adding more or new habs to my knowledge). But this has nothing to do with storage containers or anything that would be needed from SSTU.

USI's "just supplies" as a LS system seems like too simple an approach imho. I like the TAC oxygen/water/food better, and also three waste products (CO2, waste water, waste) to recycle with scrubbers etc. It's set up to be more realistic than USI LS, as USI tends to focus mostly on kerbalization vs more realistiK. There are some extra mods for TAC that make a loop for the waste products (Soylent, Greenhouse and I think even BioMass), but they are all from different people (yet using the same resources as a basis and some of their own ones that I don't see the need of supporting).

Lots of people using USI and TAC life-supports, so I'd love to see both being supported. For TAC you only need one container that has all 6 resources. As it has no other logistics for radio-actives or maintenance like UKS, there will only be one part variant.

BTW: there is USI life-support and then there is the UKS system that also requires other resources for maintenance etc. So they are not mutually-exclusive. You can run Kolonizations (UKS/MKS/OKS) without Lifesupport, and the other way around.
 

Is there a well-known mod that can make LH/Ox out of some kind of resource?

Link to comment
Share on other sites

5 minutes ago, Jimbodiah said:

More habs = longer hab period, but still limited (no way to prolong without adding more or new habs to my knowledge). But this has nothing to do with storage containers or anything that would be needed from SSTU.

USI's "just supplies" as a LS system seems like too simple an approach imho. I like the TAC oxygen/water/food better, and also three waste products (CO2, waste water, waste) to recycle with scrubbers etc. It's set up to be more realistic than USI LS, as USI tends to focus mostly on kerbalization vs more realistiK. There are some extra mods for TAC that make a loop for the waste products (Soylent, Greenhouse and I think even BioMass), but they are all from different people (yet using the same resources as a basis and some of their own ones that I don't see the need of supporting).

Lots of people using USI and TAC life-supports, so I'd love to see both being supported. For TAC you only need one container that has all 6 resources. As it has no other logistics for radio-actives or maintenance like UKS, there will only be one part variant.

BTW: there is USI life-support and then there is the UKS system that also requires other resources for maintenance etc. So they are not mutually-exclusive. You can run Kolonizations (UKS/MKS/OKS) without Lifesupport, and the other way around.
 

Is there a well-known mod that can make LH/Ox out of some kind of resource?

Yes, it is called ModuleManager :)

(simply patch the stock ISRU to add hydrolox and lh2 options; or copy the part config to make a custom LH2 based one)

Link to comment
Share on other sites

All LS boils down to what can be recycled, and what needs to be added. There is no reason to be more complex than that, IMHO. Yes, you can micromanage what is recycled at 94% vs 80%, etc, but it becomes needlessly complex as the whole thing is only as "realistic" as the least realistic part. It boils down to mass, after all. How many extra kg/day per person need to be brought along, vs what is the difference in LS system (recycler, etc) mass per efficiency. 

Real LS is so tightly integrated into spacecraft design that the idea of lego-like elements that you tack on to add capability seems needlessly troublesome to me. 

Do SSTU variants only change the appearance, or can they change mass as well? In the latter case, LS could be a variant. Take a hab module. Instead of seats increasing with radius/length, perhaps the LS capability can change as a variant. 2.5m part is 3 kerbals, 3.75m is 5. Every X m of length added can add a couple seats. The LS capability could be variants that change the total duration, and the number of seats. Base 2.5m hab with only 1 seat might have more LS supplies, and a better recycler (something RoverDude added to the MPL).

My only issue with the USILS guidelines is using mass as the multiplier for parts like the cupola, which makes zero sense to me, it seems like the volume and/or subjective factors should  dominate.

On habs, assuming IVA is a possibility at some point in the future, I might be inclined to have the hab parts not stretch finely, but in "1 floor" blocks if that is possible. So if you had an IVA of a single floor/level of a hab/lab, you could make the hab 1 level, 3 (like the stock MPL), 7, whatever, then the IVA could just use the same model over and over for each floor.

Link to comment
Share on other sites

25 minutes ago, Shadowmage said:

Yes, it is called ModuleManager :)

(simply patch the stock ISRU to add hydrolox and lh2 options; or copy the part config to make a custom LH2 based one)

No, I know that, but I think I saw a Hydrogen scoop once in one of RoverDudes mods, not sure if it is there anymore. I can patch the ISRU to make anything, but just wondering if some kind of mod already has a cycle set up.

You may also want to look at Karbonite/K+ from USI and Kethane (which has been re-released and updated).

Link to comment
Share on other sites

18 minutes ago, tater said:

My only issue with the USILS guidelines is using mass as the multiplier for parts like the cupola, which makes zero sense to me, it seems like the volume and/or subjective factors should  dominate.

That's an interesting thought. AFAIK the buoyancy system calculates volume already, that might not be as difficult a change as it might otherwise be.

Link to comment
Share on other sites

51 minutes ago, tater said:

All LS boils down to what can be recycled, and what needs to be added. There is no reason to be more complex than that, IMHO. Yes, you can micromanage what is recycled at 94% vs 80%, etc, but it becomes needlessly complex as the whole thing is only as "realistic" as the least realistic part. It boils down to mass, after all. How many extra kg/day per person need to be brought along, vs what is the difference in LS system (recycler, etc) mass per efficiency. 

Real LS is so tightly integrated into spacecraft design that the idea of lego-like elements that you tack on to add capability seems needlessly troublesome to me. 

Do SSTU variants only change the appearance, or can they change mass as well? In the latter case, LS could be a variant. Take a hab module. Instead of seats increasing with radius/length, perhaps the LS capability can change as a variant. 2.5m part is 3 kerbals, 3.75m is 5. Every X m of length added can add a couple seats. The LS capability could be variants that change the total duration, and the number of seats. Base 2.5m hab with only 1 seat might have more LS supplies, and a better recycler (something RoverDude added to the MPL).

My only issue with the USILS guidelines is using mass as the multiplier for parts like the cupola, which makes zero sense to me, it seems like the volume and/or subjective factors should  dominate.

On habs, assuming IVA is a possibility at some point in the future, I might be inclined to have the hab parts not stretch finely, but in "1 floor" blocks if that is possible. So if you had an IVA of a single floor/level of a hab/lab, you could make the hab 1 level, 3 (like the stock MPL), 7, whatever, then the IVA could just use the same model over and over for each floor.

I agree on the LS -- it all comes down to mass.  There is zero reason for three separate resources from a gameplay perspective, all it does is clutter up the part menu and resource list unnecessarily.  From a realism perspective...well.. they likely recycle/are reclaimed/re-used at different ratios... but that could all be abstracted into the 'loss factor' for the single-resource setup as well.  This is why I lean towards (and will only personally support) USI-LS; it is -just- as complex as it needs to be (from a resource perspective; I have not touched/played with any of the hab stuff, though I can't say that I'm a fan of it given what I've read on it so far).

IVAs -- unfortunately they cannot work like that; you cannot stack IVA models as each kerbal seat requires a uniquely named transform.  If you duplicate the models, the transform names are duplicated, not renamed sequentially like would be needed.  This would have to be done by using several pre-made IVAs for each internal setup, and swapping between them at runtime -- which I'm not sure is possible; the part loading sequence caches a ton of IVA related stuff, and I'm unsure how to force-reload it when the IVA setup changes, or if it is even possible.  Overall I'm just going to ignore IVAs.  Someone else can figure them out if they want to spend the time on it.

Station parts -- still in the very early concept dev stage on them... no clue yet what they will entail.  I aim to use the upcoming yet-to-be-implemented module-switching functionality to allow a single part to serve a multitude of potential functions, and to enable a truly modular setup for those parts.  Should be quite capable of making 'single part' stations for most simpler designs, or using the modules (parts) in combination for larger/more complex stations.  Overall it should cut down station part count to ~10-20% of what they currently require (30 part station down to a 3-6 part station is the goal).

Link to comment
Share on other sites

1 hour ago, Red Iron Crown said:

That's an interesting thought. AFAIK the buoyancy system calculates volume already, that might not be as difficult a change as it might otherwise be.

He suggests using the mass in the cfg as the multiplier, so it's not even actually using the mass, the part author enters it in the cfg. For USILS compatibility, I'd go with his suggestions, people with issues (like me) can always use different values :) .

Link to comment
Share on other sites

2 hours ago, Shadowmage said:

Station parts -- still in the very early concept dev stage on them... no clue yet what they will entail.  I aim to use the upcoming yet-to-be-implemented module-switching functionality to allow a single part to serve a multitude of potential functions, and to enable a truly modular setup for those parts.  Should be quite capable of making 'single part' stations for most simpler designs, or using the modules (parts) in combination for larger/more complex stations.  Overall it should cut down station part count to ~10-20% of what they currently require (30 part station down to a 3-6 part station is the goal).


Thanks for the RO pull request @Shadowmage, it worked very well :)

On the topic of cutting down part count, it would be nice to have a fuel tank that could be converted to a habitat in flight, after the fuel has been drained or used. For example, the Skylab was originally conceptualized using this 'wet workshop' concept. Since you are in the 'early concept dev' stage, I figured this was a good time to mention it as it certainly doesn't seem like a feature that could be thrown in at the end.
 

Link to comment
Share on other sites

On 3/14/2016 at 11:00 AM, Shadowmage said:

Your assumption is incorrect -- the positions of the parts within the IVA are defined in the iva config and -not- in the part config (and it is the positions in the iva config I had to patch)

TEEHEE That's why I said my logic was flawed. 

 

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...