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

[regex]

8 minutes ago, Shadowmage said:

Mmm... looking pretty tasty even without proper schematics.  Some stuff -will- be a bit off... but.. silly Russians... they just don't publish their rocket-related engineering blueprints apparently (still cannot find any good blueprints/diagrams/schematics... so proportions, measurement, and placement is all guessed at from various images... which thankfully there are at least a couple high-res ones available).

Main chamber and bell, dimensions in millimeters, will be the exact same for both the RD-107 and RD-108.

S1.53800 chamber and bell (verniers), dimensions in millimeters.

A decent page on the engine with some additional links at the bottom (where these images are from):

http://www.lpre.de/energomash/RD-107/index.htm

Edited February 15, 2016 by regex

[blowfish]

@Shadowmage Have you thought about how the vernier gimbals will work?  I've experimented with such setups myself and ran into the following issues:

• There's no easy way to distribute thrust unevenly between multiple transforms.  There might be a couple of hacky ways around this:
  • Put lots of thrust transforms on the main nozzles so that they effectively get more thrust (since thrust is evenly distributed between each transform).  Not sure if having that many force would impact physics performance.
  • Include another module that adds thrust proportional to the main module's thrust.  The reported thrust and Isp on the main engine would be wrong.
  • Include another module that adds proportional thrust to the verniers, and adds an equal magnitude negative thrust on the main engines.  Definitely hacky, but might work.
• The stock gimbal module doesn't allow single-axis gimbaling.  I almost got it working with some look at constraints, but it ended up having weird issues.

[Shadowmage]

1 minute ago, regex said:

Main chamber and bell, dimensions in millimeters, will be the exact same for both the RD-107 and RD-108.

S1.53800 chamber and bell (verniers), dimensions in millimeters.

 

Yep, that is about the extent of the 'schematic' like information I've found.  Precisely two images.  I have a third and fourth that show the flow-diagram for a single chamber, and the full engine.

But.. for F1/J-2 / etc... I can find stuff like:

 

Nice and detailed, orthographic projection, from multiple views.

But.. ohwell...  I can do it without them... I just don't -feel- as good about doing it.

 

[Shadowmage]

6 minutes ago, blowfish said:

@Shadowmage Have you thought about how the vernier gimbals will work?  I've experimented with such setups myself and ran into the following issues:

• There's no easy way to distribute thrust unevenly between multiple transforms.  There might be a couple of hacky ways around this:
  • Put lots of thrust transforms on the main nozzles so that they effectively get more thrust (since thrust is evenly distributed between each transform).  Not sure if having that many force would impact physics performance.
  • Include another module that adds thrust proportional to the main module's thrust.  The reported thrust and Isp on the main engine would be wrong.
  • Include another module that adds proportional thrust to the verniers, and adds an equal magnitude negative thrust on the main engines.  Definitely hacky, but might work.
• The stock gimbal module doesn't allow single-axis gimbaling.  I almost got it working with some look at constraints, but it ended up having weird issues.

It will use two engine modules, one for the main chambers, one for the verniers.  I've used similar setups in other parts in the past without issue -- MJ/KER even calculate the burn-time/etc properly with mixed ISP and thrusts (as near as I could tell).  For simplicity sake, both main and verniers will use the same ISP; the thrusts will be different though.

Yes, the verniers will gimbal on all axis, nothing I can do about it (as you say, stock limitations).  While I -do- have a functional single-axis constraint system that I could use (see the AJ-10-190 gimbal ring setup; it uses two different constraints, locked to a single axis, to simulate the multi-axis input), I don't think it would really be necessary and might cause problems with MJ/etc that expect those thrusts to gimbal (might not be as much of a problem with PID feedback/cycle as it would be with anything that pre-calculated  from the gimbal range).

[blowfish]

16 minutes ago, Shadowmage said:

It will use two engine modules, one for the main chambers, one for the verniers.  I've used similar setups in other parts in the past without issue -- MJ/KER even calculate the burn-time/etc properly with mixed ISP and thrusts (as near as I could tell).  For simplicity sake, both main and verniers will use the same ISP; the thrusts will be different though.

Yes, the verniers will gimbal on all axis, nothing I can do about it (as you say, stock limitations).  While I -do- have a functional single-axis constraint system that I could use (see the AJ-10-190 gimbal ring setup; it uses two different constraints, locked to a single axis, to simulate the multi-axis input), I don't think it would really be necessary and might cause problems with MJ/etc that expect those thrusts to gimbal (might not be as much of a problem with PID feedback/cycle as it would be with anything that pre-calculated  from the gimbal range).

Ah cool, makes sense.  Re: engine modules, you might want to include another module that hides the individual engine controls (events, actions, thrust limiter, maybe thrust and I_sp) and replaces them with a unified interface.  I don't think this would interfere with Mechjeb etc at all, since it's not changing how the engines respond to staging or the main throttle, just how the user interacts with them.

[JoseEduardo]

quick question, I know the RD-107 and RD-108 are both clusters of 4x main chambers and 2 and 4 verniers, but.... my mad side of the brain is curious... can we cluster the chambers or if we try to cluster it will cluster the whole thing?

like, can we create a thing with 18 chambers and verniers around it, or we should only be able to cluster the RD-107 or RD-108 themselves?

[Shadowmage]

3 hours ago, blowfish said:

Ah cool, makes sense.  Re: engine modules, you might want to include another module that hides the individual engine controls (events, actions, thrust limiter, maybe thrust and I_sp) and replaces them with a unified interface.  I don't think this would interfere with Mechjeb etc at all, since it's not changing how the engines respond to staging or the main throttle, just how the user interacts with them.

Will give some thought to the extra-GUI-interface module; though, might just leave it as-is for now/the initial implementation.

 

8 minutes ago, JoseEduardo said:

quick question, I know the RD-107 and RD-108 are both clusters of 4x main chambers and 2 and 4 verniers, but.... my mad side of the brain is curious... can we cluster the chambers or if we try to cluster it will cluster the whole thing?

like, can we create a thing with 18 chambers and verniers around it, or we should only be able to cluster the RD-107 or RD-108 themselves?

Verniers will be part of the model(s)... so these engines will be mostly non-clusterable, as it will copy the verniers for each engine.  Might make a no-vernier one specifically for clustering -- but then your entire cluster will have zero verniers and no gimballing; so not sure how useful that would be.

 

[regex]

17 minutes ago, JoseEduardo said:

quick question, I know the RD-107 and RD-108 are both clusters of 4x main chambers and 2 and 4 verniers, but.... my mad side of the brain is curious... can we cluster the chambers or if we try to cluster it will cluster the whole thing?

like, can we create a thing with 18 chambers and verniers around it, or we should only be able to cluster the RD-107 or RD-108 themselves?

The RD-107/108 and the similar RD-171 or RD-180 simply use clusters of chambers to avoid many of the problems associated with larger chambers, things that the F-1, for instance, had to overcome.  They incorporate shared turbopumps and hardware along with multiple combustion chambers and bells to create engines with excellent thrust to weight ratios and overall performance.  They are complete engines in themselves, optimized to work the way they do.  You can't simply stack more chambers/bells together without changing the shared hardware.

[JoseEduardo]

35 minutes ago, Shadowmage said:

Will give some thought to the extra-GUI-interface module; though, might just leave it as-is for now/the initial implementation.

 

Verniers will be part of the model(s)... so these engines will be mostly non-clusterable, as it will copy the verniers for each engine.  Might make a no-vernier one specifically for clustering -- but then your entire cluster will have zero verniers and no gimballing; so not sure how useful that would be.

 

but in this case, would it allow me to make a new engine with 18 chambers (not 18 RD-108) or would it be 72 chambers if I tried to make a 18 cluster?

or in other words, will the chambers be available as a single model at some point or the whole RD-107/108 will be one model/4 chambers? (not counting the verniers of course)

[blowfish]

@Shadowmage NathanKell says that the issue with gimbals should be fixed in 1.1.  Not sure if that changes your plans for the shuttle or not.

[01010101lzy]

58 minutes ago, Shadowmage said:

Verniers will be part of the model(s)... so these engines will be mostly non-clusterable, as it will copy the verniers for each engine.  Might make a no-vernier one specifically for clustering -- but then your entire cluster will have zero verniers and no gimballing; so not sure how useful that would be.

 

But in this case you can make individual veiners for clustering... Only a bit too many parts to stack on the rocket.

[Shadowmage]

46 minutes ago, JoseEduardo said:

but in this case, would it allow me to make a new engine with 18 chambers (not 18 RD-108) or would it be 72 chambers if I tried to make a 18 cluster?

or in other words, will the chambers be available as a single model at some point or the whole RD-107/108 will be one model/4 chambers? (not counting the verniers of course)

 

It will be one model file for each engine, 107 & 108; the models in those files will include the verniers in their specific locations.  Depending on how I setup them  up though, I -might- be able to release a no vernier 4-chamber (with thrust structure+pump) model file as well.  Though, honestly, you should just get the .blend file from me and set it up / export it yourself, as I have no interest in including it in the mod, but have no problem with you doing it for personal use if you want to spend the time to set it up.

 

24 minutes ago, blowfish said:

@Shadowmage NathanKell says that the issue with gimbals should be fixed in 1.1.  Not sure if that changes your plans for the shuttle or not.

I found out the cheating bit on it worked great.  Set the part-origin down near the engines/gimbals and then used the config-based CoMOffset to move it upwards/where it should be.  So engines have been integrated back into the fuselage, and back down to 6 parts.

Good to know though, was a bit of an odd bug that has effected a few parts of mine.

 

Also got the single-axis verniers working on the RD-107s (and 108s when I get there). 

 

Now I just need to finish off the models    (for both the shuttle and engines)

Edited February 16, 2016 by Shadowmage

[blowfish]

5 minutes ago, Shadowmage said:

Also got the single-axis verniers working on the RD-107s (and 108s when I get there). 

How did you do this?  With a custom gimbal?  When I tried with the stock module it sorta worked, but when the engine was pitched and the yaw input was triggered, the gimbal would wobble around a lot.

[Shadowmage]

3 minutes ago, blowfish said:

How did you do this?  With a custom gimbal?  When I tried with the stock module it sorta worked, but when the engine was pitched and the yaw input was triggered, the gimbal would wobble around a lot.

Using the custom model constraint module that I wrote; It supports standard look-constraints, and 'limited' support for locked-axis constraints (z- pointing direction, lock either x or y).  The model setup is probably much like you would expect; separate gimbal+target from visible mesh+thrust transform.  Gimbal rotates the target, visible mesh tracks to the target along the specified axis.

[Shadowmage]

Thing is actually coming along nicely; all thats is really needed on this first pass is the vernier fuel lines and possible vernier mounting brackets (thinking I'm going to brace them against the nearest bell...we'll see...).  Then of course comes all the joins and brackets/adapters/fittings.. cleaning things up.

[SpaceBadger007]

12 hours ago, Shadowmage said:

It is actually 2 of the longest + 1 of the shortest stock bays in length -- the cargo bay is the entire length of the shuttle.

This makes me very happy!

[Shadowmage]

RD-107 - First pass/initial geometry done:

Going to work on setting up the verniers and fuel-lines/etc for the RD-108's, and then will be working on cleanup and poly reduction (~20k tris at the moment...would like about half that; a big portion of those will come from cleaning up/fixing all the plumbing/bezier-curve based stuff, though the bells and turbopump may require some face reduction as well (both are 24t, could be 16-20t to save a few tris and still look acceptable))

[Jimbodiah]

Show-off!!!  

[Shadowmage]

5 hours ago, Jimbodiah said:

Show-off!!!  

Yes

Gotta do something to make it feel like I'm making actual progress.

 

In other (general) development news, I've spent a bit of time today prototyping an upgraded Engine Cluster module -- the goal of this will be to remove all of the parts for individual clusters, and allow for swapping of the number of engines (and layouts) while in the editor (while keeping all other existing functionality intact; e.g. mount selections, fairings, etc).

This was the original intent of the engine-cluster plugin, but I was unable to dedicate the time to it to fix up the interaction issues, and ended up settling for a compromised version.

Well, now I already have a functional single-part engine cluster plugin, so have no problem devoting a bit of time to trying to make it work like it was supposed to originally -- if it doesn't work out, then nothing major is lost (aside from a bit of time).  However, if it -does- work... great   All of the engine-cluster parts are one of the bits of the mod I have misgivings about, and would be glad if I could finally clean them up / unify them into a single set of in-editor parts.

Will know more in a few hours after I can do some testing on the mess of code that I've written.  Even if the initial implementation works out, I'll still have some stuff to clean up in regards to RO (more specifically, RealFuels and its ModuleEngineConfigs).

[Shadowmage]

After a bit of.... arguing... with KSP code about ConfigNodes... I have an initial working implementation of an engine-cluster module that can swap the # of engines while in the editor.  Layout / number of engine swapping works, effects work once launched, gimbals work once launched... thrust works fine.  So far it is looking good, though I still have most of the features to (re)implement, and loads of testing to do.

Hopefully this news makes at least a few of you as happy as it does for me;  the single-part-per-cluster always seemed like a hacky/sub-optimal solution, and I will be happy to finally clean that bit of mess up.

Also, if the techniques that I've setup for this are working properly, this means that I -might- be able to implement some interesting features like running a cluster on only some of its engines / selective enabling of engines.

Still need to validate that it will work with RF's ModuleEngineConfigs setup.... I imagine that it should fine (at least in flight), and if not I can likely add an inter-mod hook to support it.  Likely won't let this stop me even if it doesn't work out, as RO can always create their customized clusters the old fashioned way... by hand, with MODEL nodes and a lot of patience.

[RedParadize]

Thats great stuff! 

I didn't play this game in a while. I am mostly waiting 1.1 for obvious reason. But I think I will luch kerbal again just to see your new stuff.

You should release this!

[StickyScissors]

Question: has the gradual trailing off of thrust in SRB's been considered as an idea for this mod? IIRC the component space shuttle SRB's did this somehow, but i'm not certain it would work properly.

[ComatoseJedi]

4 hours ago, Shadowmage said:

After a bit of.... arguing... with KSP code about ConfigNodes...

I've never argued with code before. Seems like no matter how much you threaten to change it, it never does. You can't even reason with code. It's like they are written down or something. But, in any case, I am glad you've yielded positive results. I tried my luck at texturing the other day. I gave a full day of wanting to design an interplanetary command module. Needless to say, I'm getting better at modelling, but my texturing looks like a 2nd grader did it with a melted crayon with paste mixed in with it. 

[blowfish]

4 hours ago, StickyScissors said:

Question: has the gradual trailing off of thrust in SRB's been considered as an idea for this mod? IIRC the component space shuttle SRB's did this somehow, but i'm not certain it would work properly.

It's a useful feature but I don't think it's specific to SSTU.  In any case, Crzyrndm already has a mod that does that, though it's by no means perfect.

[Sudragon]

I like it how it's never hard to find this mod. Always on the front page.