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

[blowfish]

@Shadowmage One way to allow an easy LH2 toggle would be to mark the LH2 patches as :NEEDS[CommunityResourcePack,SSTU-LH2] (or make LH2 the default and have the stock fuel patches as :NEEDS[!CommunityResourcePack|SSTU-NoLH2] or something between those two), then users who wish to alter the behavior can just create an empty SSTU-LH2 or SSTU-NoLH2 folder in GameData to enable and disable the patches.  It's not a lot cleaner than the current solution, but it has the advantage of persisting when you install a new version of SSTU.

[Autochton]

4 hours ago, Shadowmage said:

Am I actually looking at an in-game Korolev Cross? 

[Kerbal01]

What is the difference between each of the 4 types of procedural SRM?

[Jimbodiah]

Segment length on the first three are different and 4th one has no segments.

[Shadowmage]

9 hours ago, blowfish said:

@Shadowmage One way to allow an easy LH2 toggle would be to mark the LH2 patches as :NEEDS[CommunityResourcePack,SSTU-LH2] (or make LH2 the default and have the stock fuel patches as :NEEDS[!CommunityResourcePack|SSTU-NoLH2] or something between those two), then users who wish to alter the behavior can just create an empty SSTU-LH2 or SSTU-NoLH2 folder in GameData to enable and disable the patches.  It's not a lot cleaner than the current solution, but it has the advantage of persisting when you install a new version of SSTU.

Ahh... I had forgotten that CRP -would- have a FOR entry because of its directory.  Still learning things with MM

With that knowledge, I should be able to alter that patch to be default whenever CRP is installed, or vise-versa.

Thanks

 

 

5 hours ago, Autochton said:

Am I actually looking at an in-game Korolev Cross? 

Yes

They at least -look- right when they decouple   (and that was with stock decouplers only; no need for jettison motors).

 

 

2 hours ago, DarthVader said:

What is the difference between each of the 4 types of procedural SRM?

 

1 hour ago, Jimbodiah said:

Segment length on the first three are different and 4th one has no segments.

Yep, that is currently the only difference between them.  I -might- setup some of the nozzles to have different ISP, or setup one or more of the segment varieties to have different thrust / burn time; but currently its just a way to get a larger variety of lengths.

[blowfish]

@Shadowmage Even if CRP doesn't have any :FOR entries, MM will still infer its existence based on the presence of the directory.  There are 3 ways to tell MM that a mod exists:

• Patches marked :FOR[<modname>]
• Existence of <modname> directory in GameData
• A plugin called <modname>.dll somewhere in GameData

[Shadowmage]

And in general news:

The dev notes this week had some quite sad points in them.

1.) No antenna system for 1.1 -- I was quite looking forward to this, and was going to add proper short range (orbital) antennas to all pods, with some parts having longer-range antennas (service modules).  Ohwell, suppose I can still add the antennas, they'll just be a bit overpowered.

"we pushed the antenna and telemetry system back meaning it won’t be a part of update 1.1" 

 

2.) No updated PBR shader/rendering.  I'm honestly not sure what they were referring to with that one, or how that is going to work out.  Can we use the 'standard shader', or not?  Suppose only time will tell...

"On the flip side, the new (PBR) lighting model will also have to be pushed back to beyond 1.1 over performance concerns with the real time reflections. We’ll be looking into creating a more efficient, custom solution for this problem at a later date." 

And... even more   (was actually far more excited about the rendering updates than I was the antennas...).  So.. sadly, there -still- will not be any reflective/shiny textures.

But.. on the bright side, this means that I likely won't be spending weeks/months doing texture updates for 1.1, as it sounds like they are using some sort of hacked shader/rendering that should be compatible with existing textures and setups.

 

So... there goes the 2n'd and 3'd most important features from 1.1 for me (the first being 64-bit support).  At least they haven't cut the GUI system updates out.... those are fairly important to me as well, though I have a hard time getting excited about them -- would love some nice GUIs... but ugh... GUI work generally sucks (AWT/SWT/Swing/WinAPI... every GUi system I've coded with... all are terrible; I've never found a GUI library that was pleasant to use... either they are too simple to do anything real and usable, or too bloated, complex, and too much of a cluster to efficiently/quickly work with).

[Jimbodiah]

Yeah, I figured Squad would back down on all the things they promised, and I think 1.1 will be full of new major issues/bugs judging from their devnotes. The carrot they were dangling in front of us is slowly starting to rot.

[davidy12]

@Shadowmage: Don't forget N-Body physics and Unity 5. 

[blowfish]

2 minutes ago, davidy12 said:

@Shadowmage: Don't forget N-Body physics and Unity 5. 

I have seen no mention of N-body physics and I doubt Squad would do that anyway.

As for Unity 5, that's really the main point of 1.1 and drives all the other improvements (64 bit, UI changes).

[davidy12]

8 minutes ago, blowfish said:

I have seen no mention of N-body physics and I doubt Squad would do that anyway.

As for Unity 5, that's really the main point of 1.1 and drives all the other improvements (64 bit, UI changes).

Also, I think Roverdude is making a deployable heat shield. Strange, Scott Manley said they would in 1.0.5 preview

Edited February 12, 2016 by davidy12

[Guest]

Hi there Shadowmage, I heard you were making an RD-107-alike and looked a few pages back but couldn't find it (or in the OP)?  I did see pre-fab R-7 booster tanks which are looking spot-on, though.  Would you be at all interested in taking up the cause for "naked" RD-107/108 engines?  I very much like the preview engines you have in this pack and you are highly spoken of in RO circles.

Edited February 12, 2016 by regex

[Shadowmage]

5 minutes ago, regex said:

Hi there Shadowmage, I heard you were making an RD-107-alike and looked a few pages back but couldn't find it (or in the OP)?  I did see pre-fab R-7 booster tanks which are looking spot-on, though.  Would you be at all interested in taking up the cause for "naked" RD-107/108 engines?  I very much like the preview engines you have in this pack and you are highly spoken of in RO circles.

Well, I added a temporary RD-107/8 placeholder with yesterday's update (re-used/re-scaled and clustered an existing engine; no verniers), just to make the boosters a bit more usable.

However, yes, I will be making a proper model at some point -- kind of funny that you bring this up now, as I was -just- looking over my images and stuff to start laying out the initial geometry.  Sadly, I still have not been able to locate any highly detailed schematics for those engines (as I can for all the old US engines)... so I'm not sure how fast this project will progress. 

When they are done though, they should be pretty much like the images in your post (naked/thrust-frame only).  Will also be including a R-7 mount/shroud for each (core/booster), though these will obviously be limited to a single scale/diameter.

Will likely be the next engine/set of engines that I do...so...perhaps a few weeks to a month?  (already have a few other WIP/planned projects in the pipeline that I need to cleanup first)

[Guest]

16 minutes ago, Shadowmage said:

Will likely be the next engine/set of engines that I do...so...perhaps a few weeks to a month?  (already have a few other WIP/planned projects in the pipeline that I need to cleanup first)

That sounds great, thanks for your consideration!

[NathanKell]

@Shadowmage awesome!

For details, maybe @Niemand303 has or can get the drawings you need? Or @asmi ?

[Jimbodiah]

Lookin'goooood!

[stratochief66]

@Shadowmage so one of the most amazing features of SSTU I haven't adapted to RO yet is the built in ullage thrusters on the procedural upper stages. Since pretty much all engines have limited ignitions with RealFuels, ullage RCS systems are basically mandatory, and it is awesome that SSTU already contains a part with that built in. I managed to get them to burn real fuels:

        MODULE
        {
            name = ModuleRCS
            thrusterTransformName = SC-GEN-RCS-4F-T-ThrustTransform
            thrusterPower = 0.025
            resourceFlowMode = STAGE_PRIORITY_FLOW
            atmosphereCurve
            {
                key = 0 270
                key = 1 100
                key = 4 0.001
            }
            PROPELLANT
            {
                ratio = 0.495
                name = MMH
                resourceFlowMode = NO_FLOW
            }
            PROPELLANT
            {
                ratio = 0.505
                name = MON3
                resourceFlowMode = NO_FLOW
            }
        }

 

However, no matter what I set the thrusterPower to, they still burn roughly 30L/s of fuel, producing ~88 kN of force (based on a 200T craft, experiencing 0.0447G of acceleration when forward ullage engaged) Since there are 8 thrusters aimed downward, that comes to roughly 1 kN per nozzle, which I would imagine correlates to thrusterPower = 1 (?)

I haven't yet RO/RealFuel-ified the SSTU - SC-GEN-RCS-4F-T part, but I can't see why I would have to alter that part to affect the thrusterPower on this one. I don't understand thrusterTransformName's that well. I would have figured if the  SSTU - SC-GEN-RCS-4F-T part was affecting the thrusterPower here, it would also disagree with me changing it over to burning MMH & MON3, but again I could be wrong.

Edit: I believe I found the governing code: https://github.com/shadowmage45/SSTULabs/blob/ace1747c842373d0fb17e91176f4c54739a923ab/GameData/SSTU/Parts/ShipCore/tanks/SC-MUS-CB.cfg#L44

But my question is, why do it this way instead of the standard way, by allowing modders to alter the ModuleRCS as usual?

Also, would it be possible for you to add similar ullage providing RCS to the EUS (SSTU-SC-B-HUS) and ICPS (SSTU-SC-B-ICPS) parts at some point?

Edited February 13, 2016 by stratochief66

[Shadowmage]

12 hours ago, stratochief66 said:

@Shadowmage so one of the most amazing features of SSTU I haven't adapted to RO yet is the built in ullage thrusters on the procedural upper stages. Since pretty much all engines have limited ignitions with RealFuels, ullage RCS systems are basically mandatory, and it is awesome that SSTU already contains a part with that built in. I managed to get them to burn real fuels:

        MODULE
        {
            name = ModuleRCS
            thrusterTransformName = SC-GEN-RCS-4F-T-ThrustTransform
            thrusterPower = 0.025
            resourceFlowMode = STAGE_PRIORITY_FLOW
            atmosphereCurve
            {
                key = 0 270
                key = 1 100
                key = 4 0.001
            }
            PROPELLANT
            {
                ratio = 0.495
                name = MMH
                resourceFlowMode = NO_FLOW
            }
            PROPELLANT
            {
                ratio = 0.505
                name = MON3
                resourceFlowMode = NO_FLOW
            }
        }

 

However, no matter what I set the thrusterPower to, they still burn roughly 30L/s of fuel, producing ~88 kN of force (based on a 200T craft, experiencing 0.0447G of acceleration when forward ullage engaged) Since there are 8 thrusters aimed downward, that comes to roughly 1 kN per nozzle, which I would imagine correlates to thrusterPower = 1 (?)

I haven't yet RO/RealFuel-ified the SSTU - SC-GEN-RCS-4F-T part, but I can't see why I would have to alter that part to affect the thrusterPower on this one. I don't understand thrusterTransformName's that well. I would have figured if the  SSTU - SC-GEN-RCS-4F-T part was affecting the thrusterPower here, it would also disagree with me changing it over to burning MMH & MON3, but again I could be wrong.

Edit: I believe I found the governing code: https://github.com/shadowmage45/SSTULabs/blob/ace1747c842373d0fb17e91176f4c54739a923ab/GameData/SSTU/Parts/ShipCore/tanks/SC-MUS-CB.cfg#L44

But my question is, why do it this way instead of the standard way, by allowing modders to alter the ModuleRCS as usual?

Also, would it be possible for you to add similar ullage providing RCS to the EUS (SSTU-SC-B-HUS) and ICPS (SSTU-SC-B-ICPS) parts at some point?

 

Those parts dynamically modify the thrust for the RCS dependant upon the size of the tank being used.  At 'defaultDiameter' the thrust will be 'defaultRcsThrust'; from there it will be scaled (square/2n'd power) up/down depending upon diferent tank sizes.

So... the line you are looking to modify is in the SSTUCustomUpperStage:

'defaultRcsThrust = 1'  -- change that to whatever value you want it to be for the default tank size.

Why do it this way?  How else could I dynamically alter the thrust? (I need a persistent, non-altered value for the 'base' thrust; could not use the ModuleRCS field, as it will be changed/updated by the CUS plugin)

And you can still alter the thrust, you merely need to do it through the CUS plugin.

 

ICPS/HUS -- umm.. no current plans.  You could always patch in some RCS modules through MODEL nodes (as that would likely be all that I would do).  I'll try and play around with this a bit when I have time... will be easier for me to do, as I have the model file to tell me precise positions

Edited February 13, 2016 by Shadowmage

[stratochief66]

2 hours ago, Shadowmage said:

Those parts dynamically modify the thrust for the RCS dependant upon the size of the tank being used.  At 'defaultDiameter' the thrust will be 'defaultRcsThrust'; from there it will be scaled (square/2n'd power) up/down depending upon diferent tank sizes.

So... the line you are looking to modify is in the SSTUCustomUpperStage:

'defaultRcsThrust = 1'  -- change that to whatever value you want it to be for the default tank size.

Why do it this way?  How else could I dynamically alter the thrust? (I need a persistent, non-altered value for the 'base' thrust; could not use the ModuleRCS field, as it will be changed/updated by the CUS plugin)

And you can still alter the thrust, you merely need to do it through the CUS plugin.

 

ICPS/HUS -- umm.. no current plans.  You could always patch in some RCS modules through MODEL nodes (as that would likely be all that I would do).  I'll try and play around with this a bit when I have time... will be easier for me to do, as I have the model file to tell me precise positions

 

Yup, I eventually worked it out. Definitely makes sense in the end.

I'm trying to think of a way to also include autoscaling tanks that contain the requisite RCS hypergolics for RealFuels. I will look at some point to see if you do a similar thing with Monopropellent in the stock version.

[Shadowmage]

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.28-pre7

Quite a few bug fixes, more texture work on WIP parts, and some general cleanup and organization.  See the link for full change-log and downloads.

[Kerbal01]

Pushed SRM sep  to 18.6 gees, absurd.

[stratochief66]

There is an issue in the SC-ENG-J-2X-Clusters.cfg file with the 4x cluster.

    @name = SSTU_ShipCore_ENG-JX-2x4

    @title = SSTU - SC-ENG-J-2X x 4

I noticed this while trying to configure the engines & clusters for RO.

 

• UPDATE - Change category on old SRB parts to 'none' so that they cannot be used on any new vessesls. They have been officially deprecated and will be removed in a near-future release.

Those actual correspond to some already configured RO parts we would prefer not to disappear. Would it be possible to leave those components in the mod, even if they are deprecated in the stock version?

[Shadowmage]

3 hours ago, stratochief66 said:

There is an issue in the SC-ENG-J-2X-Clusters.cfg file with the 4x cluster.

    @name = SSTU_ShipCore_ENG-JX-2x4

    @title = SSTU - SC-ENG-J-2X x 4

I noticed this while trying to configure the engines & clusters for RO.

 

• UPDATE - Change category on old SRB parts to 'none' so that they cannot be used on any new vessesls. They have been officially deprecated and will be removed in a near-future release.

Those actual correspond to some already configured RO parts we would prefer not to disappear. Would it be possible to leave those components in the mod, even if they are deprecated in the stock version?

Engine name -- noted and fixed.  (This means it will break any craft using the old incorrect 4x cluster)

 

SRB's -- They will be removed from the main distribution entirely starting with next weekends' release, however they will still be available in the legacy-parts pack for those so inclined to download/install it (but will receive no further updates or support).  Their functions have been entirely replaced by the modular SRB's and I have no reason to keep them in the main distrubution -- they are only increasing the memory footprint and part-list count unnecessarily.

Edit:  Alternatively, I can show you how to create single-model SRBs using MODEL nodes with the models that the MSRB module uses.  This would basically consist of adding a MODEL node for the main body, one for the nozzle, and one for the nosecone; scaling each as appropriate (2.5m default scale, same as the old parts).  There would be a slight difference in height as the new 'long' segments are 5m rather than 5.8m; but some of this is compensated for by the front skirt that they all have (2.5m).  This could be done entirely through a patch / custom part.cfg file, and would not require any of the old models or assets, and would use all stock modules.

Let me know if this something you are interested in and I'll work out an example and some instructions / measurements.

Edited February 14, 2016 by Shadowmage

[stratochief66]

2 hours ago, Shadowmage said:

Engine name -- noted and fixed.  (This means it will break any craft using the old incorrect 4x cluster)

 

SRB's -- They will be removed from the main distribution entirely starting with next weekends' release, however they will still be available in the legacy-parts pack for those so inclined to download/install it (but will receive no further updates or support).  Their functions have been entirely replaced by the modular SRB's and I have no reason to keep them in the main distrubution -- they are only increasing the memory footprint and part-list count unnecessarily.

Edit:  Alternatively, I can show you how to create single-model SRBs using MODEL nodes with the models that the MSRB module uses.  This would basically consist of adding a MODEL node for the main body, one for the nozzle, and one for the nosecone; scaling each as appropriate (2.5m default scale, same as the old parts).  There would be a slight difference in height as the new 'long' segments are 5m rather than 5.8m; but some of this is compensated for by the front skirt that they all have (2.5m).  This could be done entirely through a patch / custom part.cfg file, and would not require any of the old models or assets, and would use all stock modules.

Let me know if this something you are interested in and I'll work out an example and some instructions / measurements.

Nah, that is alright. Perhaps I will pick the current (or next) version of SSTU as the official one for RO, since there is still plenty of it that we still need to configure for RO. Spending more time to reconfigure to get the same function that already exists is sort of counterproductive. Perhaps when @JoseEduardo gets back and starts helping out again?

[Jimbodiah]

I'm keeping José busy with political discussion and Elite trade routes