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

[blowfish]

5 hours ago, Nightside said:

Welcome to the forums @mg1142, the RealFuels mod totally changes how fuel tanks from other mods function and may be incompatible with SSTU, unless RealFuels includes special config files for SSTU. 

There was code to make the work together.  I haven't tried both mods together very recently though.

[Shadowmage]

22 hours ago, mg1142 said:

I have just installed SSTU mod and using Real Fuel too and I have the following bug.

 

When using the SSTU - SC TANK - MFT-A - Standard Tank amount of fuel in the tank will stay at 2kL liter instead of increasing when size or diameter is increased. 

Do you know why is that? Am I missing something? 

 

EDIT: Btw, same happens with the Spherical Tank...

As @blowfish stated, there is some code (and patch files) that should let the two mods work together (basically uses RF instead of the SSTU-volume container setup).

Could you upload your KSP.log file to a file-sharing site and post the link here?  (dropbox, pastebin, etc).  This can be found in your main KSP directory, the same folder with the KSP executables.

The log will contain debug statements on the interaction of the two mods' code; it should tell me what bit is not working.

[Mike`]

Hey guys. I have to say really great job at all the code and models. Since i have seen mods like this one, i can't imagine playing stock again.

I've just noticed some weirdness with engine mount sizes. The following engines allow a _smaller_ minimum mount size when in dual-layout than in single-layout: LMAE, both LR-81 variants.

The following engines have a too large minimum size in single-layout and have the same size when you configure them to use dual-layout: LMDE, RD 0110 and the 3 NRV series.

Are those sizes calculated by code, or can i adjust some config values to fix this?

[Shadowmage]

Updated release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.6.36.138

Quite a few fixes, a fairly long list of mod-integration additions from @Jimbodiah, and adds recoloring support to the SC series of spacecraft (SC-A,B,C).  See link for change-log and downloads.

[Shadowmage]

3 hours ago, Mike` said:

Hey guys. I have to say really great job at all the code and models. Since i have seen mods like this one, i can't imagine playing stock again.

I've just noticed some weirdness with engine mount sizes. The following engines allow a _smaller_ minimum mount size when in dual-layout than in single-layout: LMAE, both LR-81 variants.

The following engines have a too large minimum size in single-layout and have the same size when you configure them to use dual-layout: LMDE, RD 0110 and the 3 NRV series.

Are those sizes calculated by code, or can i adjust some config values to fix this?

Mostly calculated through code, with some 'hints' given from the parts and other config files.  The entirety of the system for it is a bit complex, so I can't really tell you where/what to edit until I dig into it a bit (could be one of several config values, or even a code-side error).

I'm less concerned with the min size being too small than I am with the default size being correct.  As long as the default size for the layouts looks appropriate, that is the most important bit; after all, there is nothing stopping players from clipping/overhanging parts in stock KSP either.  Some of the overhang is even intentional, as when combined with the 'spacing' adjustment on the engine clusters, you can get some layouts/clusters to fit onto mounts/in areas that they would not otherwise.  Large discrepancies are not intentional or desired though, so some of it may be actual errors.

If you would like to open up an issue ticket with the list of effected engines, I'll look into cleaning them up for a future release (the ones that are not intentional).

[Mike`]

11 minutes ago, Shadowmage said:

Mostly calculated through code, with some 'hints' given from the parts and other config files.  The entirety of the system for it is a bit complex, so I can't really tell you where/what to edit until I dig into it a bit (could be one of several config values, or even a code-side error).

I'm less concerned with the min size being too small than I am with the default size being correct.  As long as the default size for the layouts looks appropriate, that is the most important bit; after all, there is nothing stopping players from clipping/overhanging parts in stock KSP either.  Some of the overhang is even intentional, as when combined with the 'spacing' adjustment on the engine clusters, you can get some layouts/clusters to fit onto mounts/in areas that they would not otherwise.  Large discrepancies are not intentional or desired though, so some of it may be actual errors.

If you would like to open up an issue ticket with the list of effected engines, I'll look into cleaning them up for a future release (the ones that are not intentional).

Thanks, i will open a ticket. Yeah, sure, being too small isn't really an issue, but minimum and default sizes are too large for the engines i posted (in single-layout mode at least). And i found it very weird that suddenly the min mount was smaller when you use a dual-engine layout, i guess that info might help tracking down the problem.

Edited August 27, 2017 by Mike`

[Mike`]

3 hours ago, Shadowmage said:

Updated release is available:

I'm sorry to have found an issue in the new release, i think the length and burntime of SRBs somehow changed. 

In the new patch, the SRB's are alot longer and the burntime is inversely proportional to diameter, thus thinner SRBs burn longer but have very low TWR, to the point that 0.65m diameter SRBs can't push their own weight.

I downgraded to the previous release and SRBs work fine again.

Can open an issue for that aswell if you want.

Edited August 27, 2017 by Mike`

[Shadowmage]

16 hours ago, Mike` said:

I'm sorry to have found an issue in the new release, i think the length and burntime of SRBs somehow changed. 

In the new patch, the SRB's are alot longer and the burntime is inversely proportional to diameter, thus thinner SRBs burn longer but have very low TWR, to the point that 0.65m diameter SRBs can't push their own weight.

I downgraded to the previous release and SRBs work fine again.

Can open an issue for that aswell if you want.

Sure;  was doing some work on the SRB code for the upcoming upper-stage SRB, and must have goofed something up regarding fuel calcs / thrust calcs.

Probably won't get that one fixed until I have time to finish working through the upper-stage SRB stuff, which will probably be awhile with the way things are going at work.  While I may have the time to 'fix' the problem in code, I completely lack any time to do testing on the fixes, which is what got us to this place to begin with (not enough time to test everything for every release).

 

[OscarJade]

Hello all. Is there a trick to inflating the station parts? They inflate just fine in the VAB, but won't when in orbit, or even on the launch pad when I test it.

Love the mod, BTW - thanks! 

[Mike`]

Quote

Probably won't get that one fixed until I have time to finish working through the upper-stage SRB stuff

No worries, take your time. I'm still amazed by the engine and tank layouts, really great idea, works and looks amazing.

Edited August 28, 2017 by Mike`

[tater]

[Shadowmage]

10 minutes ago, OscarJade said:

Hello all. Is there a trick to inflating the station parts? They inflate just fine in the VAB, but won't when in orbit, or even on the launch pad when I test it.

Love the mod, BTW - thanks! 

The inflatables require a volume/mass of 'RocketParts' (or 'Specialized Parts and MaterialKits if the USI patch is enabled) in order to inflate the modules.  This is to simulate a 'kit out' process of installing all of the support structure and infrastructure for the module (wiring, computers, recyclers, etc).

To inflate them in-flight, attach a tank/container containing the specified tonnage of RocketParts (can be seen in the inflatables' right-click menu as Resources Required: xxx tons).  Once the needed resources are present on the vessel, you should be able to press the inflate button; the resources will be consumed, and the part will inflate and be fully usable/crewable.  The parts will even accept partial shipments of resources, so you can ship the resources up in smaller batches if needed.

And thanks, glad you are enjoying it

 

 

[OscarJade]

I apologize for the silly question, but will any 'rocket parts' do? I installed KIS and loaded a container with (literally) some rocket parts (i.e., LV-909s, etc) and mass of loaded container says 11.5. Not sure if this is measured in tons or not, though. At any rate, inflation doesn't work.

[Shadowmage]

7 minutes ago, OscarJade said:

I apologize for the silly question, but will any 'rocket parts' do? I installed KIS and loaded a container with (literally) some rocket parts (i.e., LV-909s, etc) and mass of loaded container says 11.5. Not sure if this is measured in tons or not, though. At any rate, inflation doesn't work.

Not a silly question at all.

The RocketParts in question is the RockerParts resource (used by EPL), and not actual parts to build rockets   (though I could see where the confusion might arise there)

Take one of the MFT fuel tanks, click on 'configure container', and fill it with the RocketParts resource.

[Rodger]

7 hours ago, Shadowmage said:

The inflatables require a volume/mass of 'RocketParts' (or 'Specialized Parts and MaterialKits if the USI patch is enabled) in order to inflate the modules.  This is to simulate a 'kit out' process of installing all of the support structure and infrastructure for the module (wiring, computers, recyclers, etc).

BTW looks like the latest release doesn't include the optional patches folder at all. But also, the USI patch needs a fix:
@PART[*]:HAS[@MODULE[SSTUInflatable]]:AFTER[SSTU]
{
    @resourceName = MaterialKits
    @inflationCost *= 1.33333
}

Should be:

@PART[*]:HAS[@MODULE[SSTUInflatable]]:AFTER[SSTU]
{
    @MODULE[SSTUInflatable]
    {
    @resourceName = MaterialKits
    @inflationCost *= 1.33333
    }
}

BTW just using MK and no SP for inflation is fine, it's consistent with other USI inflatables.

[Shadowmage]

11 hours ago, Rodger said:

 

BTW looks like the latest release doesn't include the optional patches folder at all. But also, the USI patch needs a fix:
@PART[*]:HAS[@MODULE[SSTUInflatable]]:AFTER[SSTU]
{
    @resourceName = MaterialKits
    @inflationCost *= 1.33333
}

Should be:

@PART[*]:HAS[@MODULE[SSTUInflatable]]:AFTER[SSTU]
{
    @MODULE[SSTUInflatable]
    {
    @resourceName = MaterialKits
    @inflationCost *= 1.33333
    }
}

BTW just using MK and no SP for inflation is fine, it's consistent with other USI inflatables.

Thanks for catching that one; fixed in dev, and will be available... erm... whenever I re-merge the optional patches folder into the distro (probably never).

Optional patches -- yep, they have been removed from the distro due to too many support problems and questions of 'why did all my stock parts disappear (when I installed this optional patch that removes them)?'  Some of them may be merged into the main distro in the mod-integration patch sets (like the patch pointed out above).  Some, such as the part-deletion patches (and other patches that change existing parts), will stay as a stand-alone / external / optional download.

[Shadowmage]

Today's main bit of progress was the testing and cleanup for a new feature/enhancement -- the ability to lock and set manual rotation on 'tracking' solar panels.

Works far better on single panel setups than it does on the integrated panels, as there is only a single 'rotation' control that needs to control all panels in the part (or at least all panels managed by a single module).  On parts with multi-axis tracking, it locks -all- axis and uses the same rotation for all, which is not quite ideal.  But it does work, and even 'less than ideal for a few parts', is still more control than is available in current releases.  Not a 'huge' feature by any means, but something I've been personally wanting for quite some time (sometimes I like to simulate non-tracking solar panels on spacecraft, also good for making screenshots).

Also managed to fix up the solar-panel rotation persistence -- the solar panels should restore themselves to exactly whatever state they were in when you unloaded the craft.  This means they might take a moment to re-track to the sun from their last-saved/loaded rotation, but at least they won't start in default rotation every time they are loaded.  (I previously had some code in place that was supposed to also re-orient them to the sun on vessel re-load, but it never seemed to work, so has been removed;  am investigating proper solutions to effect that same outcome, so that when you reload a vessel, it will 'seem' like it has been active the entire time you were away)

Manged to fix up most of the currently reported issues yesterday, including some unfortunate bugs that were introduced in Sundays release.  Need to do a bit more testing on the current state of things, and investigate one or two more outstanding problems, but am hoping to publish an updated release tomorrow with all of the fixes in place.

[Mike`]

Looks good, although i'm just now slowly getting far enough into the game to use solar panels.

I just had some fun experiencing the SSTU heatshields after being used to the durable stock ones. I've read that a medium shield should be fine for a minmus return, but failed on my first try.

I had a 830 kg (including shield), 1.25m diameter unmanned probe with some science experiments returning from minmus, periapsis set to ~25 km, hit the atmosphere with about 3050 m/s. The ablator usage was roughly -1.6, the ablator was fully used up and after that the shield exploded. My probe survived, because the service bay had no trouble with the heat after the shield exploded, but i redid the experiment at different PEs/steeper return angles to see the effect of those. On my second try, with a periapsis of slightly below 0, the shield still exploded. Third try, periapsis of -41km, the shield returned successfully with roughly 9.x ablator left.

Is this the intended performance? I fear that using a little more mass, eg a manned mission which would already double the weight roughly, would need a little stronger shield. Still a good job though, because reentry certainly becomes more challenging than just slap on a heatshield now.

Also i guess with those non-stock-like performances, i should update the remove-stock-elements-patch to also remove the comparatively overpowered stock heatshields.

Edit:

I just did some further tests using the 1.25m light heatshield, 2,2t vessel (pod + mk1 crew cabin), reentering from ~85km kerbin orbit:

-43km periapsis, 2290 m/s reentry speed, ablator ran out at 39km

-251km periapsis, 1930m/s reentry speed, ablator ran out at 27km

-283km periapsis, 1900m/s reentry speed, ablator ran out at 23km

The heatshield exploded every time.

Edited August 30, 2017 by Mike`

[Shadowmage]

3 hours ago, Mike` said:

I had a 830 kg (including shield), 1.25m diameter unmanned probe with some science experiments returning from minmus, periapsis set to ~25 km, hit the atmosphere with about 3050 m/s. The ablator usage was roughly -1.6, the ablator was fully used up and after that the shield exploded. My probe survived, because the service bay had no trouble with the heat after the shield exploded, but i redid the experiment at different PEs/steeper return angles to see the effect of those. On my second try, with a periapsis of slightly below 0, the shield still exploded. Third try, periapsis of -41km, the shield returned successfully with roughly 9.x ablator left.

That sounds about right; 25km = death, 45km = skip off, 30-40km = 'the sweet spot' for re-entry, and is what the shields were tuned for (specifically 35km).  They are also intended to be near-fully used up by the time you land, and should have minimal/no ablator left by the time you leave the danger zone (below ~1500m/s @ ~20-30km).  I felt that the stock heat shields were far too much of a 'throw one on and ignore re-entry' type setup, and far too powerful, and also mostly overkill (most re-entries landed with 3/4 ablator left on stock heat shields, which is just so much wasted mass...).

However it sounds like I might need to increase their efficiency slightly.  ~1t does not sound like too big of a probe for that shield, it should probably be able to handle up to ~1.5t.  I would probably have to see some pics though, as that might be more probe than I'm thinking it is.

Of course, if medium is not enough, there is always 'heavy' and 'extra heavy'    They can both handle higher heat loads, and have more ablator (ex-heavy is the same stats as heavy, but with 2x the ablator).  These shields also cope decently with multi-pass aerobraking; sometimes a first pass at ~45-50k can make the second pass much less dangerous.

 

5 hours ago, Mike` said:

Also i guess with those non-stock-like performances, i should update the remove-stock-elements-patch to also remove the comparatively overpowered stock heatshields.

If you have suggestions for the optional patches set, feel free to post them up here or on the Github issues list.  I'm nowhere near done working on those patches yet and what currently exists was merely a half-hearted first pass at mod-integration for my personal game setup (which is why it is all USI/NF/EPL patches).

Many of them will be moved into the mod distro as 'mod integration' patches, but some will be staying in the optional patches setup (such as part removals).  I'm open to suggestions/improvements to both.

[ComatoseJedi]

Anyone having a problem attaching the Lander Tank? It doesn't seem to want to attach to any attach node. When it does, it deletes the node until I delete the part and try again. I can try to provide logs, but since it takes like 10 minutes for me to exit KSP, I don't see how a log would provide any information while building in the VAB.

 

[tater]

Regarding ablator, I think even 25km is too high, resulting in a long dwell time, and overheating. I usually aim below 20km.

 

 

Thought I already posted this...

Just thought I'd drop these here. While these sorts of folding structures might be out of scope, some of the folding mechanisms, particularly in the  second video, are intriguing.

 

 

 

[mg1142]

On 26/08/2017 at 6:08 PM, Shadowmage said:

As @blowfish stated, there is some code (and patch files) that should let the two mods work together (basically uses RF instead of the SSTU-volume container setup).

Could you upload your KSP.log file to a file-sharing site and post the link here?  (dropbox, pastebin, etc).  This can be found in your main KSP directory, the same folder with the KSP executables.

The log will contain debug statements on the interaction of the two mods' code; it should tell me what bit is not working.

Hello and thank you @Shadowmage for your reply. 

Sure, I will update my log file! Really glad that you take so much of your time for people with minor problems like us.

Let me reinstall the SSTU mod on my game 1.2.2 and I'll upload the LOG file.

 

[Mike`]

8 minutes ago, Shadowmage said:

That sounds about right; 25km = death, 45km = skip off, 30-40km = 'the sweet spot' for re-entry, and is what the shields were tuned for (specifically 35km).

Interesting, note, however, that i had to set periapsis to _negative_ 40km to successfully reentry, 0km and everything above was too shallow and the shield exploded.

Quote

However it sounds like I might need to increase their efficiency slightly.  ~1t does not sound like too big of a probe for that shield, it should probably be able to handle up to ~1.5t.  I would probably have to see some pics though, as that might be more probe than I'm thinking it is.

Yup, i think so, too. An mk-1 pod with a single parachute and the medium shield is ~ 1118kg, so quite a bit heavier but well within 1.5t. I think i would also like an increase in the maximum ablator you can put on the shields to reduce the mass difference between a shield with 100% ablator and the next stronger shield with only some ablator.

If you want i can do some further testing using just the mk-1 pod or something.

Also, i just noticed that the difference between the SC-V CM reentry module and the version without shield is 220kg, while the 2.5m medium shield is 711kg - those numbers should be balanced about the same, right?
Considering apollo's heat shield seemed to weight about 850kg, something like 220kg-300 kg seems reasonable for the 2.5m medium shield.

 

Quote

If you have suggestions for the optional patches set, feel free to post them up here or on the Github issues list.  I'm nowhere near done working on those patches yet and what currently exists was merely a half-hearted first pass at mod-integration for my personal game setup (which is why it is all USI/NF/EPL patches).

Many of them will be moved into the mod distro as 'mod integration' patches, but some will be staying in the optional patches setup (such as part removals).  I'm open to suggestions/improvements to both.

Once i included most of the stock parts SSTU has replacements for in the remove-stock-parts-patch, i'll post it.

[Shadowmage]

17 minutes ago, Mike` said:

Interesting, note, however, that i had to set periapsis to _negative_ 40km to successfully reentry, 0km and everything above was too shallow and the shield exploded.

Hmm.. well that is certainly not the intended behavior then.  Honestly, it should burn up even faster when doing a re-entry like that (due to too high of 'peak' heat).... so obviously something is amiss on the code/tuning for those.  When doing something like that it should explode very shortly after hitting atmo, at/around the 30km range, or at least that was the intention.

The intention was:

Too shallow  (pe too high, >40km in stock scale) = burn up from dwell, basically you run out of ablator before you slow down enough and the remaining heat melts the craft.

Too steep (pe too low, <30km in stock scale) = burn up from peak heating, from hitting the thicker atmosphere at too high a velocity.

Hmm... perhaps I need to add some sort of dynamic-pressure based adjustment to the ablator efficiency and/or use-rate....

 

18 minutes ago, Mike` said:

If you want i can do some further testing using just the mk-1 pod or something.

For the 1.25m, that is probably an excellent test-case, and sounds like a good place to start working on the balance.  (Though for 2.5m I consider the stock mk1-2 pod to be grossly overweight, and not a good case for testing)

If you would really like to 'play' with the balance on them, there are a couple values in the config files that determine how the heat shield reacts to various heat loads.

In the SC-GEN-MHS.cfg file, if you find the MHS module, the following line determines how fast ablator is used:

ablationEfficiency = 8000

It is essentially how much 'flux' each unit of ablator can absorb before being consumed/blown off/whatever happens to ablator.  Higher values = more resilient heat shield that will last longer at any given heat load.

Secondly, there are the heat-response curves, found in GameData/SSTU/Data/HeatShieldTypes.cfg.  These are specified as standard KSP float curves (key = <input value>  <output value for given input>), which in this case is 'key = <part temp> <flux to remove per second>'.  It is the second values that you would want to adjust/play with (the flux-to-remove-per-second).  In theory these curves were supposed to allow for the part to heat up to a given point before the ablation kicked in, increase ablation as heat increased to a point, but still allow for the re-entry to 'overpower' the ablation rate (resulting in higher part temps, and eventual explosions/loss of the heat shield part). 

It was working during testing when I developed the modules for the integrated heat-shields in pods, but that was several releases ago, and I'm not sure that I did much testing on the stand-alone heat-shields (they likely react quite differently due to different mass ratios, and the very inaccurate thermodynamics model KSP uses by simulating one part at a time; might need more tuning, or possibly even custom curves defined for the stand-alone versions).

On that note -- how are the 'integrated' heat shields in the SC-pods working out?  Are they performing as intended in regards to capabilities (light = LKO, medium = mun/minmus, heavy = 'low speed' interplanetary, ex-heavy = 'high speed' interplanetary)?

(If I'm going to do a tuning pass on them, might as well make sure they are -all- working as intended)

 

27 minutes ago, Mike` said:

Also, i just noticed that the difference between the SC-V CM reentry module and the version without shield is 220kg, while the 2.5m medium shield is 711kg - those numbers should be balanced about the same, right?

Not necessarily (also not addressing that those are prototype parts with placeholder stats, zero effort was given to balance those parts);  the stand-alone heat shield includes extra dry mass for 'structure' (which is itself mostly a hack to cope with KSPs previously mentioned poor thermo simulation; super-light parts really don't work well for heat-shields, the lighter it is the worse it works).

With the pods the difference between the CM and CMX is less than the heat shield mass, as the CMX versions should have more RCS fuel and higher dry mass to simulate the additional 'supplies' on board (with USI-LS, etc, that mass is actually in the supplies rather than simulated, and the parts dry mass should be adjusted accordingly).  At least that is the intention, how well that has made it into the part configs is open for debate...

 

 

1 hour ago, mg1142 said:

Hello and thank you @Shadowmage for your reply. 

Sure, I will update my log file! Really glad that you take so much of your time for people with minor problems like us.

Let me reinstall the SSTU mod on my game 1.2.2 and I'll upload the LOG file.

 

If you are still playing on KSP 1.2.2, you will need to use one of the older releases of SSTU -- the newer versions are for KSP 1.3+ only.

Link to most recent 1.2.2 compatible version -- https://github.com/shadowmage45/SSTULabs/releases/tag/0.5.34.134

(note that it will not have many of the more recent feature additions, such as the recoloring system)

[blowfish]

A steeper re-entry will reduce overall ablator use.  Peak heating will be higher, yes, as will peak g loading, but the total heat load over the entire re-entry will be less.  So if a gentler re-entry causes you to run out of ablator, that kind of makes sense.  Not saying the balance is correct at the moment, but the overall trend of the results seems to make sense to me.