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

[Shadowmage]

Upcoming for this next week:

AJ10-137 (Apollo Service Module Engine) -- Available as an engine/cluster, and integrated into the service module (see below).  First pass rough geometry, likely will be a day or three before it gets to the texturing stage.

 

I'm going to re-use as much of the existing SM texture as I can; I think the detailing turned out well, and I can probably re-use the entire side-panel texture area without problem.  The color/noise texture will be cleaned up (lighter, less streaky/blotchy), and it will have a new specular map (shinier/smoother); but all the paneling detailing will stay in place (bolts/ports/radiators/etc).  Will save quite a bit of time as well.

I'm going to clean up the to/interior a bit more, and redo the engine heat-shield / fill port area geometry, but that likely won't take too long for any of it.  The HGA antenna array has been redone to take advantage of what I have learned; same poly count, but much more detail/better edge flow.

Will use the AJ10 engine above (integrated into the model), along with the yet-to-be-finished RCS port geometry/models. 

 

 

 

 

[Shadowmage]

1 hour ago, RedParadize said:

Yeah I edited the config. Added one of your wonderfull fairing module and changed the decoupling node to the lower one. That should be good enough for now.

Oh, another thing, if you do this:

  Hide contents

MODEL
{
    model = SSTU/Assets/SC-B-131a-DP
    position = 0, 0.86586, 0
    scale = 0.55, 0.55, 0.55
}

The docking port fit the inner ring of the standard Clamp-o-tron docking port, It looks legit to me.

 

And again another edit:

Question1: What file I need to edit to change the Intestage Petal Adapter weight ?

Question2: Does your parachute module take in consideration ground elevation ? Better not land on ground! Can we edit full deployment altitude ?

 

#1 - SSTU/Parts/ShipCore/general/SC-GEN-IPA

the fields are (not present in config, but you can add them):

costPerBaseVolume = 1500
costPerPanelArea = 50
massPerBaseVolume = 0.5
massPerPanelArea = 0.025

 

#2 - Not yet, still needs to be implemented (the GUI/adjustment bit).  Currently it can only be set through config.

Here are all of the config fiels for the parachute that should/will do something.  Everything but temp and atm (density) are implemented.  Temp/atm will be related to the 'safe to deploy' status, but I need to do a bit more research (both on stock mechanics, and on high-speed parachute mechanics).

wobbleMultiplier = 10
lerpDegreePerSecond = 45
autoCutSpeed = 0.5
mainSemiDeploySpeed = 2
mainFullDeploySpeed = 2
mainSemiMinAtm = 0.01
mainSemiAutoAlt = 8000
mainFullMinAtm = 0.2
mainFullAutoAlt = 750
mainMaxTemp = 800
drogueSemiMinAtm = 0.001
drogueSemiAutoAlt = 25000
drogueFullMinAtm = 0.005
drogueFullAutoAlt = 17000
drogueMaxTemp = 1400
drogueSemiDeploySpeed = 2
drogueFullDeploySpeed = 2

 

[RedParadize]

1st: Thats quite nice! 

2nd: thanks for the info. I will see what I can do with this.

3rd: More questions: how your custom heatshield works? whats the difference compared to stock? Is there any way to customize it ?

[Jimbodiah]

Amen to 1.1, can't happen soon enough.

[RedParadize]

31 minutes ago, Jimbodiah said:

Amen to 1.1, can't happen soon enough.

 

Even when 1.1 will happen, we will have to wait quite a while to see existing mod adapt to it. But I agree. 

[Shadowmage]

17 minutes ago, RedParadize said:

1st: Thats quite nice! 

2nd: thanks for the info. I will see what I can do with this.

3rd: More questions: how your custom heatshield works? whats the difference compared to stock? Is there any way to customize it ?

Heat Shield - It is float curve based, with a few other simple settings.  Most things just are not present in the new CM config as they use the default values

MODULE
{
name = SSTUHeatShield
resourceName = Ablator
heatShieldVector = 0, -1, 0
//minimum start temp for ablation process
ablationStartTemp = 500
//minimum dot product of shield vector and wind direction that the shield will have any effect
heatShieldMinDot = 0.2
//beyond this point the shield does not become more effective (to allow for some deviation from 'perfect' without losing shield effectiveness)
heatShieldMaxDot = 0.8
//determines effectiveness of each unit of ablator material - this matches the stock 'pyrolysisLossFactor' of the stock heat shield (KW of heat flux rejected per mass unit = resource specific heat capacity * ablationEfficiency). This represents the additional bonus to the heat rejection due to pyrolysis outgassing, which really only simulates that the heat would never have entered the heat-shield in the first place
ablationEfficiency = 6000
//this floatCurve determines actual ablator used per input temperature beyond start temp (e.g 2500 temp - 500 start = 2000 for input value, 0.0050 from float curve = 2000*0.005 = 10 ablator per second used, multiplied out further by the flux-per-ablator factors listed above = final temp reduction in KW )
//higher settings will use more ablator and expel more heat/flux
//default settings are:
heatCurve
{
     key = 0 0.00002
     key = 50 0.00005
     key = 150 0.00010
     key = 750 0.00015
     key = 1000 0.00020
     key = 2000 0.00050
     key = 3000 0.00100
     key = 10000 0.002000
}

}
 

It is not fully implemented yet; I want to add a few more modes for active and passive thermal soak type heat-shields (e.g. Space Shuttle, some icb-missiles), and clean up some of the other settings related to using it on integrated parts (a lot of the stock thermal system I don't really understand yet, nor is thermodynamics one of my stronger points.. or anything I've even studied).  But I believe the current settings should give some usable configuration and allow the module to be re-used on other parts, and/or tweaked for larger-scale systems.

One of the most important settings is 'heatCurve' -- if you find you are overheating, increase the decimal numbers.  Feel free to add more keys for more control.  At default, it doesn't even start ablating noticeably until it hits ~1500k part skin temperature, which matches the settings on the stock module that I tested.  Still some tweaking to be done in the curve to be sure    This setting simulates the surface area of the heat-shield - larger decimal values represent more surface area for the same mass = more ablation per second = more heat dissipation = lower overall temps for any given load and capability to handle higher input heat loads.

The other important setting is 'ablationEfficiency' -- if you find you are using too much ablator (and don't want to add more to the part), increase this number accordingly.  Higher value = more heat rejected-per-ablator-unit.  Changes to this setting -also- directly effect the overall effectiveness of the heat-shield, but in a singular, linear, manner.  Higher values here will reject more heat for less ablator;  as the results of heatCurve is units-per-time, it will need to be changed to accommodate the higher flux-per-unit from the change efficiency value.

 

[Motokid600]

What files do I need to keep if I only want the engines? I thought I was successfully able to trim out just the engines with their corresponding models and textures. However somewhere I mustve went wrong because the engines are no where to be found in game. I also wanted your launch escape tower ( boost protective cover ). That showed up. But no engines.

So I'm not sure where I went wrong. Your folder structure is a little strange so I could've made a mistake somewhere.

Edited December 13, 2015 by Motokid600

[Shadowmage]

23 minutes ago, Motokid600 said:

What files do I need to keep if I only want the engines? I thought I was successfully able to trim out just the engines with their corresponding models and textures. However somewhere I mustve went wrong because the engines are no where to be found in game. I also wanted your launch escape tower ( boost protective cover ). That showed up. But no engines.

So I'm not sure where I went wrong. Your folder structure is a little strange so I could've made a mistake somewhere.

I can't say off the top of my head... there are quite a few models and textures (and the plugin of course)    The engines are all plugin based, and need the mount models.  So engines, mounts, textures, fairing texture, and plugin.  And ModuleManager, as all of the clusters are built with MM.

Have had a few requests for it, and I had previously considered it, so I'll look into packing up an 'engines only' package a bit later today.  Might even have one more engine to stick in it if I can get it finished up in reasonable time   

[Motokid600]

Cool I'll take another look at it in the meantime with that information. That'd be great Shadowmage thanks so much.

[Shadowmage]

AJ10-137 (Apollo-SPS) Engine is coming along nicely -- texture first pass, only about 1/3 done:

 

[Shadowmage]

Updated testing pre-release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.24-pre2

Also available is an engines only-download pack (untested, but should work).  Install it like any other mod; it contains only the engines + SRBs and the things necessary for them to function.  It is also available from the link above.

 

I'll work on cleaning up the modules a bit and issuing a bug-fix release a bit later in the week.

[blowfish]

Minor request: Would it be possible to put the texture packs in a separate folder in GameData (e.g. SSTU-TexturePacks)?  It would make installing updates a lot easier.

[VenomousRequiem]

3 minutes ago, blowfish said:

Minor request: Would it be possible to put the texture packs in a separate folder in GameData (e.g. SSTU-TexturePacks)?  It would make installing updates a lot easier.

Seconded! Though couldn't we do that ourselves somehow?

[blowfish]

6 minutes ago, VenomousRequiem said:

Seconded! Though couldn't we do that ourselves somehow?

Parts of the configs rely on things being in specific locations in GameData.  This includes the texture sets.

Of course, this means we could still do it ourselves, but it would be a lot of work on each release that would probably negate the benefits of that setup in the first place.

[Shadowmage]

Totally doable; only requires editing the texture locations in the texture-set configs... so not really that much work since I cleaned up the definitions.  Probably like 20-40 lines to update, and could all be a quick search/replace.

Will get this in place for the next release, as it would make it easier on my end too

[ComatoseJedi]

Where did you get the specs for the aj10-137? Personally, it seems a bit under powered for one engine. Then again, it maybe just the way it is to fit to specs on the sm. Like I told you before, I know nothing of the real specs of these systems, except for what I read, you may have a different idea in mind on how these things should operate, hence why it's your mod. 

Also looking at conceptual designs from the Deep Space Habitat and other systems in conjunction with this design. A 500 day operating mission? Sounds legit, lol..

Edited December 14, 2015 by lynwoodm

[Shadowmage]

42 minutes ago, lynwoodm said:

Where did you get the specs for the aj10-137? Personally, it seems a bit under powered for one engine. Then again, it maybe just the way it is to fit to specs on the sm. Like I told you before, I know nothing of the real specs of these systems, except for what I read, you may have a different idea in mind on how these things should operate, hence why it's your mod.

https://en.wikipedia.org/wiki/Apollo_Command/Service_Module#Service_Propulsion_System

https://docs.google.com/spreadsheets/d/1VJtB_ma_ZW1HGOtkfO05KQm07zoGvmkGY3JZFbHs0s4/edit#gid=0

Basically, its thrust is terrible for its size, even in real life.  Though, the stats on it are a bit... slim, most sources agree roughly on the thrust.  From there I applied the same scaling as for the rest of the engines.

Yes, its terrible; I'll probably be increasing it quite a bit (and its weight as well, to maintain TWR).  I want to increase the thrust on a few of the other engines as well, but I still need to make a few more engines to know what gaps need filling.

[Shadowmage]

General development update

• Have finished initial geometry for the SC-A-SM
  • includes a new stand-alone science/antenna part, the High-Gain-Antenna array
  • HGA geometry is finished, unwrapped, baked, and is undergoing texturing currently.
• Updated the existing SC-A-SM texture a bit, removed unused parts, kept the base cylinder details, remapped new geometry onto texture.  Basically the only part being kept was the normals and side-paneling details (bolts/ports/radiators).  Have even changed around the base coloring to give it a bit more of an unpainted metallic look.  Still work to be done, but is mostly presentable.
• Includes engine bell geometry from the AJ10-137 (just the bell, no need for all the plumbing, as it is hidden anyway).
• Includes automatic lower fairing around the engine.  Will also include a second node at the end of the main cylinder for use with the Interstage Petal Adapter.
• Cleaned up the in-editor lag when right-clicking on parts.  This was caused by every fairing on every part rebuilding itself every time anything was right-clicked or moved; have adjusted the fairing code to only rebuild/recalculate only when it needs to, rather than when -anything- changes.  This would not effect the flight scene at all, but was aggravating while in the editor.
• Have not yet done the RCS ports (geometry done, but needs unwrapped/baked/textured), but I will likely have them done in the next couple of days.
• RCS ports and HGA on the SM are done through MODEL nodes, so they could potentially be replaced or removed through patch.
• Renders/etc of updated SM/HGA/RCS/etc will be forthcoming as soon as I do the unwrap and initial texturing on the RCS ports.

 

I've already accomplished the majority of my goals for this week regarding modeling and texturing / new parts (RCS stuff + finishing a few textures is all that is left), so should be able to spend quite a bit of time later in the week cleaning up the new modules (Parachute, Heat-Shield).

For the plugins my goal is to straighten out the HeatShield module to remove many of its quirks/allow it to function more logically (need to figure out how stock does thermodynamics / what one flux unit represents), and to clean up the Parachute module interaction (Action groups, atmo pressure/thermals/safe-to-deploy stuff).  All seems like it should be doable, though some will require some investigation/learning/reverse engineering.

[Jimbodiah]

starting to sound like a job

[RedParadize]

37 minutes ago, Jimbodiah said:

starting to sound like a job

That doesn't sound good. Hope there is still some fun left!

[Jimbodiah]

Scary sjit when 8 boosters overtake you and intersect in front of you... Trying to make my Delta II fly properly.

https://www.youtube.com/watch?v=SERr8G7g3Og

Edited December 15, 2015 by Jimbodiah

[Shadowmage]

LoL... in regards to that video, I just have to ask, how?  It looks like those boosters are moving at warp speed once decoupled.

[RedParadize]

At full force, the decoupler are very strong, specialy for light sub 2.5 parts. What I do is I reduce the decoupler solid fuel to about 20 for regular SSTU sides booster. Its good enough to push them a good 50m away. You can also reduce both solid fuel and trust power of the decoupler. It work great.

[Shadowmage]

So, in regards to upper-stage RCS/attitude control, I thought I would share this.  I have circled the visible reaction control thruster blocks in red; note how -tiny- they are....

 

And this is what they actually look like up close:

 

And here is the new part that I have modeled for the upper-stage (a few more variants forthcoming):

 

 

 

 

 

 

[Shadowmage]

And here is an updated render of the SM with all of the accessories in place (RCS, HGA, Engine):

Edit - and render of the attached CM, e.g. CSM stack:

 

 

Edited December 15, 2015 by Shadowmage