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

[Jimbodiah]

First attempt to make some RealPlumes. Can't get the engines with the black extensions to work yet, but the other base engines look cool already

http://dasher.nl/kerbal/SSTU_RealPlume.rar  (requires RealPlumes and SmokeScreen)

Still some work to do though   This mod also changes the sounds to more realistic ones instead of the standard pink noise.

 

Spoiler

 

Spoiler

 

 

Edited December 21, 2015 by Jimbodiah

[01010101lzy]

4 hours ago, Jimbodiah said:

First attempt to make some RealPlumes. Can't get the engines with the black extensions to work yet, but the other base engines look cool already

http://dasher.nl/kerbal/SSTU_RealPlume.rar  (requires RealPlumes and SmokeScreen)

Still some work to do though   This mod also changes the sounds to more realistic ones instead of the standard pink noise.

 

  Hide contents

 

  Hide contents

 

 

Wow, amazing!

(still couldn't get the point to RealFuels-ize those extendable engines...)

[JoseEduardo]

11 hours ago, Jimbodiah said:

First attempt to make some RealPlumes. Can't get the engines with the black extensions to work yet, but the other base engines look cool already

http://dasher.nl/kerbal/SSTU_RealPlume.rar  (requires RealPlumes and SmokeScreen)

Still some work to do though   This mod also changes the sounds to more realistic ones instead of the standard pink noise.

 

  Reveal hidden contents

 

  Reveal hidden contents

 

 

have you tried/do these work in RO?

if they do, would you mind doing a PR in the RO github? I miss these in RO 

[Jimbodiah]

Nah, I am glad I can get them to work in stock   Fak, I had to restart KSP like 30 times to test them and get them to where they are  Installed Quick Launch just for this.

I'm also at a loss how to get the clusters to use the same plumes, and why the extending engines (RL10A/B) won't work.

Edited December 21, 2015 by Jimbodiah

[JoseEduardo]

for the clusters you need to re-do all the patches, adding a :FINAL in them, when I helped Shadowmage with the configs in the new clusters I talked to him about having these, he didn't add but forgot to remove that in 3 or 4 clusters, that idea I had later proved to be a bad move because it broke RO, and Shadowmage fixed my mistake in the following patch....

if you want you could get the RO patches for SSTU and keep only the files with clusters (Layouts, upper stages, lower stages, Nova, Saturn, SLS and DIRECT), only problem is that mount size, names and engine spacing will be under RO standard...

alternatively, if you want to make your own stock patch here's all you need to do, add these to every single cluster included in the original release:
https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/RO_SuggestedMods/SSTU/SSTU_DIRECT.cfg#L2-L4

then add a :FINAL to every cluster that came with the pack, you should end up having something like this patch:
https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/RO_SuggestedMods/SSTU/SSTU_DIRECT.cfg#L2-L89

you would need a new file of course, just so you don't loose your work with a new update

as for the extending engines, they use a different engine module, so only Shadowmage should be able to give a light on how to have new efects in these

[Jimbodiah]

Right now the realplume configs are in their own file, I don't want to change Mage's files as that will mean updating on every new release. I'll take a look at your configs after dinner.

Spoiler

Fine-tuning the HUS/ICPS engines right now.

Edited December 21, 2015 by Jimbodiah

[ChrisMetal]

12 hours ago, Jimbodiah said:

First attempt to make some RealPlumes. Can't get the engines with the black extensions to work yet, but the other base engines look cool already

 

 

  Hide contents

I ran into the same problem - I absolutely can't get RealPlume to work with the engines that have the movable extensions.

 

 

 

 

  Reveal hidden contents

 

 

 

[VenomousRequiem]

Instead of restarting the game to test the plumes, do what I do! In the space centre screen, hit alt+f11 and it'll pull up a Module Manager thing. It lets you reload the configs and stuff so you can reset them without resetting the game! ShadowMage actually taught me that.

[Jimbodiah]

Yeah, that doesnt work for me. alt-F12 brings up a screen for the unlimited fuel etc, but I can't find any option to reload.

[JoseEduardo]

it's Alt+F11 for ModuleManager, Alt+F12 is for the game's debug

also, not all MM patches can be updated with Alt+F11

[Jimbodiah]

Ah, got it... can't be outside to use it.

gheghe... database reloaded 101%... found the KSP memory leak!!

 

I updated the .rar above to have the latest versions including the ISPC and HUS tank/engine parts.

 

The HUS:

Spoiler

 

 

Edited December 21, 2015 by Jimbodiah

[Jimbodiah]

Jose, I'm lost with those links you sent. Don't know how to implement the plume stuff into that. This is all new to me.

[Motokid600]

What's the reason for the low isp numbers both in atmo and vac? There easily the best looking engines I have, but they are the worst performing.

[Randazzo]

I both love those engines and hate those engines. Clearly I need to go back to the drawing board...

Seriously though, those look amazing.

Edit: And I know I've been in here before, but they just look that good.

Edited December 21, 2015 by Randazzo

[blowfish]

12 minutes ago, Motokid600 said:

What's the reason for the low isp numbers both in atmo and vac? There easily the best looking engines I have, but they are the worst performing.

Which engines?  And what are you comparing them to?  The SSTU engines are probably a lot more specialized than stock engines (i.e. first stage engines won't perform well in a vacuum), but the Isp values are well within the range of stock engines.

[VenomousRequiem]

22 minutes ago, Motokid600 said:

What's the reason for the low isp numbers both in atmo and vac? There easily the best looking engines I have, but they are the worst performing.

All of the engine are balanced something like 64% of the real engines, so any balancing problems are probably because of the IRL variants.

Maybe you're talking about the F1? It has a pretty low ISP in both atmosphere and vacuum, but only because it's optimized for thrust!

[JoseEduardo]

1 hour ago, Jimbodiah said:

Jose, I'm lost with those links you sent. Don't know how to implement the plume stuff into that. This is all new to me.

you don't, these are two distinct things, keep the plumes you have, but in order for it to be applied to the clusters you need to re-do the cluster patches like I did for RO, the big change is that it excludes the cluster part SSTU made, and re-creates it after everything has been applied to the engine (hence why it needs a :FINAL in it), so the way it works now is that SSTU clusters are made prior the effect has been added to it, and with that change they are applied after RealPlumes

unless something changed in the effect code, because in the early days of the module I managed to make FASA F-1, J-2, RL-10 and M-1 clusters and the Real Plumes were all working as intended (I have pics to prove that)

[Shadowmage]

16 hours ago, 01010101lzy said:

Adding a CoM offset to command pods may be a good idea...

(or maybe develop a module to change CoM offset in flight?)

//CoM Offset for lifting reentry
@PART[SSTU_ShipCore_B_CM]
{
	%CoMOffset = 0, 0.0, 0.07
}
@PART[SSTU_ShipCore_A_CM]
{
	%CoMOffset = 0, 0.0, 0.05
}
@PART[SSTU_ShipCore_A_CMX]
{
	%CoMOffset = 0, 0.0, 0.05
}

You are more than welcome to include this in your personal games; but no, I am not going to offset the COM laterally.

Including an in-flight COM change - possibly, but not for months.  Have too much to work on already.

Also note, the CMX pods are -not- intended to be used for re-entry.  They have no parachutes, no heat-shield, and no regular CoP/CoL offset; they are intended more for orbital freighters/tugs/busses and long-term missions that do not require atmospheric entry/re-entry.

[Jimbodiah]

I get what you are saying, but lack the know-how of these configs at the moment

Proof: haha, I believe you

[VenomousRequiem]

You could also totally use the CMX pods for like... LES testing like the Little Joe II rocket. Of course... the kerbals would die, huh? They should totally have unmanned control.

[Shadowmage]

1 hour ago, Motokid600 said:

What's the reason for the low isp numbers both in atmo and vac? There easily the best looking engines I have, but they are the worst performing.

The engines are balanced for where they would sit on the ISP curve if the 'real world' ISP curve were normalized onto the 'KSP' ISP curve, using their SL-VAC ratio.  Hence the worst performing real-world engine will become the worst-performing KSP engine, for any given statistic.

For example; the F1.  Real world it has an ISP of 265-310, giving it a vac-ratio of 0.85.   KSP has vacuum ISP values between 290 and 350.  Real world vacuum ISP ranges from 290-450.  Real-world F1 has vacuum ISP of ~310 (sits at 0.125 on the 'curve line' between min and max).  Map that onto the 0.125 point between KSP min and max, you get the KSP vaccum ISP of 302.  Apply the SL/VAC ratio to determine the sea-level ISP of ~254.

Thrust has been scaled for KLOX engines to (0.64 * 0.64)% of the thrust (direct squared-linear scaling).  HLOX engines get an additonal 'bonus' fudge factor to thrust to compensate for lack of LH2 fuel/tanks in stock KSP.  After thrust is determined, I apply the real-world engines TWR to determine 'real-world scaled' mass, and them multiply that by 4 to get the 'KSP heavy-as-freaking-bricks' engine mass and TWR.

All of this ensures that the engines I'm creating certainly won't be 'better' than the stock engines by any noticeable margin (not on ISP at least), keeps the TWR ranges within those of stock engines, and keeps all of the real-world inspired engines balanced relative to each-other.

Really, there is not much wiggle room in the balancing without breaking the real-world-relative balancing of these engines, or without making them just 'too good'.  Overall I'm fairly happy with the general balance of them, though there are a few that could perhaps use some hand-tweaked thrust increases (mostly because stuff in KSP is -heavy- compared to real life).  Mostly the thrust-increase will apply to smaller engines; as 'small' stuff in KSP is much heaver than the equivalent scaled real-world loads would have been.  So I might be implementing a general thrust-bonus-curve that weights the bonus more towards the lower-end engines (think 2-3x thrust for the smallest, 1x thrust for the largest, mostly linear interpolation inbetween).

 

1 hour ago, blowfish said:

Which engines?  And what are you comparing them to?  The SSTU engines are probably a lot more specialized than stock engines (i.e. first stage engines won't perform well in a vacuum), but the Isp values are well within the range of stock engines.

 

1 hour ago, VenomousRequiem said:

All of the engine are balanced something like 64% of the real engines, so any balancing problems are probably because of the IRL variants.

Maybe you're talking about the F1? It has a pretty low ISP in both atmosphere and vacuum, but only because it's optimized for thrust!

Indeed, exactly as it was intended to .  Lifter engines are for -lifting things-, and generally have terrible efficiency (F1/F1B).  Second stage / sustainer engines have higher ISP and lower thrust, and are not intended to be used for lifting purposes (and generally -can't- due to their poor SL-thrust) (RL10, J2).  A -few- full-range engines exist that try to balance thrust and efficiency; again these stats are based on the stats of the real-world engines that do this (RS-25, RS-68).

 

A good point of note regarding the currently available engines -- not all of them have been developed yet, so there exist some pretty large gaps in engine coverage.  I do intend on having several smaller lifter engines (Merlins, H1/S3), as well as a few larger upper-stage engines (J2-X, RL60).

1 hour ago, Randazzo said:

I both love those engines and hate those engines. Clearly I need to go back to the drawing board...

Seriously though, those look amazing.

Edit: And I know I've been in here before, but they just look that good.

 

Thanks    Have had to learn/learned a ton while doing them, and still learning/improving my techniques.

I must say though, nothing wrong with the work you have done.  Different styles certainly, but you have executed your style very well;  they look quite professionally done and certainly fit in with stock parts better than mine do/would :).

[Shadowmage]

And, no, I haven't been just idling the past few days.  Have been a bit tired due to the weather around here (terrible snow-storms; have about 1 1/2 ft of snow in my yard and on the roads around here), but still making decent progress.

Got the SC-B-BPC geometry adjusted/reworked yesterday, and a decent start on the SC-B-SM as well.

The new SC-B-CM geometry is nearing completion; needs a tiny bit more geometry work, and then on to unwrapping/etc:

And, have finished the rework of the 1.25m 'standard' docking port (down from 4k tris to 1.2k tris)  -- This geometry will be the 'base' geometry that will be used for the upcoming station parts and other docking-port reworks.
(New is in front, old is in the rear; showing both for comparison)

 

[JoseEduardo]

29 minutes ago, Jimbodiah said:

I get what you are saying, but lack the know-how of these configs at the moment

Proof: haha, I believe you

all you need to do is grab all the cluster configs that come with the SSTU release, add an exclusion patch for each default SSTU cluster (like the 3 line example shown in the first link) and then, add them again AFTER the exclusion have been made, but this time you need to add a :FINAL at the end of he header

the final result should look something like the second link, basically all you need to do is copy and paste

31 minutes ago, Shadowmage said:

You are more than welcome to include this in your personal games; but no, I am not going to offset the COM laterally.

Including an in-flight COM change - possibly, but not for months.  Have too much to work on already.

Also note, the CMX pods are -not- intended to be used for re-entry.  They have no parachutes, no heat-shield, and no regular CoP/CoL offset; they are intended more for orbital freighters/tugs/busses and long-term missions that do not require atmospheric entry/re-entry.

oh, so that's what that is for.... I was going to ask but I forgot

[Jimbodiah]

26 minutes ago, Shadowmage said:

And, no, I haven't been just idling the past few days.

Hey, it's a game... even if you were slacking in front of the TV, that's not up to us   Enjoy, take it easy, don't burn out.

Re the engines: the small ones are all for orbital stuff, very low thrust. The F1 clusters are some of the most powerful I have seen in the game, on my test rig I literally destroy the platform when I fire them up to 100% and the struts begin to wobble. Like Mage says, there are some holes in the line-up, I have brought that up as well in the past, but there are a lot of engines planned for future releases. The J2 seems like a good in-between, but it's very low atmospheric thrust means there is a hole between the low end and the RS25/F1/Clusters. Just add moar boosters (or clusters) in the meantime.

 

btw: last version for real-plumes with the SRBs added now. I will keep finetuning while launching... and maybe bribe Jose to help with the clusters.   download

Edited December 21, 2015 by Jimbodiah

[Motokid600]

Wow great breakdown shadowmage, thank you. I was just curious as to the reasoning behind engine stats and you gave me just that lol. Works for me I needed a reason to create bigger rockets anyway