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

[VenomousRequiem]

God, all of these new engines are looking amazing! Good work, Shadow.

[riocrokite]

great engines!

[Shadowmage]

an customizable engine mount like the S-II and S-IVB would be awesome for heavy upper stages

That is the plan

Should have a single part per stock stack-size that allows you to select the type and # of engines (and thus cluster layout). Still a bit to figure out, but should have some preliminary mock ups later tonight (hopefully).

God, all of these new engines are looking amazing! Good work, Shadow.

great engines!

Thanks Still tons of work to do on them, most are in pretty rough shape at the moment (literally, have just done rough geometry work on them). But should be plenty good to do the initial testing with and finish the design for the mounting system.

Should have a couple of more to show later today, including a new custom/derivative engine (I'm getting -much- faster at the rough geometry work on them... now it only takes 2-4 hours rather than 2-4 days ).

Still missing a selection of smaller engines, esp. lifters. Anyone have suggestions that I could/should research? Will likely end up using some of the larger engines scaled down for the time being to fill in the 0.625/1.25/1.875m lifter categories.

And yes, I will be doing a set of 1.875m parts; no reason to skip it, as it will all/mostly be rescaled parts from larger diameters. Have added a 1.875m 2-man command pod and service module onto the 'todo' list, though they will have to come after I finish off the rest of the core parts (tanks/engines/upper stages).

[blowfish]

Amazing work

Should have a single part per stock stack-size that allows you to select the type and # of engines (and thus cluster layout). Still a bit to figure out, but should have some preliminary mock ups later tonight (hopefully).

I'd be careful with this, primarily because other mods (namely RealFuels) (1) Don't use ModuleEnginesFX and (2) Have other modules trying to modify the engine module - and on that note (3) bad things happen when more than one module tries to modify a part's mass. There might be ways to make this work, but there are a lot of interactions to think about.

Still missing a selection of smaller engines, esp. lifters. Anyone have suggestions that I could/should research? Will likely end up using some of the larger engines scaled down for the time being to fill in the 0.625/1.25/1.875m lifter categories.

Other than the Merlins? The RS-27A used on the Delta II launcher has about a 1m diameter. The AJ26/NK33 used on some of the Antares rockets has about a 2m diameter ... Kerbal scaled it might fit on a 1.875m launcher.

[RedParadize]

I love 1.875. Can we have the fuel tank in 1.875 ?

[JoseEduardo]

That is the plan

Should have a single part per stock stack-size that allows you to select the type and # of engines (and thus cluster layout). Still a bit to figure out, but should have some preliminary mock ups later tonight (hopefully).

Sweet, when you release them I will start trying to make a RO config for them

I'd be careful with this, primarily because other mods (namely RealFuels) (1) Don't use ModuleEnginesFX and (2) Have other modules trying to modify the engine module - and on that note (3) bad things happen when more than one module tries to modify a part's mass. There might be ways to make this work, but there are a lot of interactions to think about.

that's one thing I was thinking about the customizable engines, we have done configs for the lower and upper stages, but they don't change their mesh or any stat, so it was pretty straightforward... We can only know how will they react with RF/RO after shadowmage releases them and we (stratochief and I) start working on their RO config

I'll keep in touch with him, if we (RO front) can't find a way out for this I can always go crying to shadowmage and ask for help looking at him like this

like I did with the tanks

btw, bonus stuff for those wanting a RO config for SSTU, we already have a working SLS (Block I, Block II and MPCV) in the RO github repo, and thanks to Shadowmage who did the orange cryo texture the folks that want orange SLS can be happy, as well as those who want a white and black one:

Javascript is disabled. View full album

btw, it's still a WIP, not all parts are supported yet, like the lander parts, and changes can and will happen, and ANY RO related issue should be reported in the RO thread, not here

EDIT: Shadowmage, got one idea for the SRBs, since the nosecones are there just for aerodynamics because KSP doesn't handle double staging, would it be possible to have a separate part for SRB separation? you could keep the current nosecones in the meses if one just wants them for aerodynamics, but add a new part with these nosecones having separatrons (tweakable for each SRB variant for the bottom ones) to be attached when you select the flat cap

the models and textures are already there, they would just need the separatrons to be added to them

Edited October 21, 2015 by JoseEduardo

[Shadowmage]

Amazing work

I'd be careful with this, primarily because other mods (namely RealFuels) (1) Don't use ModuleEnginesFX and (2) Have other modules trying to modify the engine module - and on that note (3) bad things happen when more than one module tries to modify a part's mass. There might be ways to make this work, but there are a lot of interactions to think about.

My choices are either plugin-based cluster manipulation with stats loaded from config; or making 20(engines) * 6 (stack sizes) * 9 (cluster variants) different engine parts (1080 parts, less as not all are available in all combos, but still many hundreds). I don't think anyone wants that kind of editor bloat, and I don't want to make that many different parts. Not when I can get it down to 6 editor parts.

It is a known caveat that there might be mods it will not play nicely with 'out of the box'. As with RF/RO/etc, I might need to do some compat patching on my end. However, as with the fuel tanks, it will all be config based, so most anything should be changeable through simple MM patch. Honestly though, the ability to use engine clusters for me far outweighs any incompatibility problems. Many ideas I cannot realize in-game due to KSPs part-count limitations; and removing that restriction from the engines/clusters would be simply awesome.

Other than the Merlins? The RS-27A used on the Delta II launcher has about a 1m diameter. The AJ26/NK33 used on some of the Antares rockets has about a 2m diameter ... Kerbal scaled it might fit on a 1.875m launcher.

I was not able to find any concrete data on the Merlins; especially there was a lack of diagrams and bell diameter information. However, I rough-guessed about where they would be based on the stats I did have, and have added 6 different Merlin variants to the list (B / B-vacuum, C / C-vaccum, D / D-vacuum) (they might not even really exist in those combinations...but w/e).

AJ26 seems like one I could look into; already have a few references/info/pics saved on it.

RS-27A - not sure I've seen that one mentioned before (or run across it)... will definitely look into it though, seems like it is in the size range that I need.

Current engine list:

(smallest at top, largest at the bottom, colored by engine-mount size)

Please let me know if you spot any vastly incorrect stats (isp, thrust, mass). Also, if you have any other suggestions to fill in the empty spots. Likely nothing based on real life will use the biggest mount sizes (2.625, 3m), I will likely come up with some custom/derivative designs to fill in the 'super-huge' engine section (s).

The engines named such as M1B, M1C are the Merlin variants (M1B is lifter, M1BV is vacuum variant). If you have concrete stats on these, would be good as well. Many were just guessed/inferred.

The entire dark-green section at the top is likely going to be filled with thrusters/large RCS systems... not quite sure yet, suggestions welcome.

Edit -- forgot to mention, before anyone asks, the RS-69 and RS-69B listed on the sheet is a custom derivative/variant of the RS-68 that has been optimized for clustering and made more compact, and the B sub-variant comes with an extendable nozzle for superb vacuum performance.

- - - Updated - - -

I love 1.875. Can we have the fuel tank in 1.875 ?

Yes, they will be coming in a near-future update (probably the same time I release the initial engine testing stuff).

- - - Updated - - -

Sweet, when you release them I will start trying to make a RO config for them

that's one thing I was thinking about the customizable engines, we have done configs for the lower and upper stages, but they don't change their mesh or any stat, so it was pretty straightforward... We can only know how will they react with RF/RO after shadowmage releases them and we (stratochief and I) start working on their RO config

I'll keep in touch with him, if we (RO front) can't find a way out for this I can always go crying to shadowmage and ask for help looking at him like this

http://www.boqnews.com/wp-content/uploads/2015/01/gatodebotas.jpg

like I did with the tanks

btw, bonus stuff for those wanting a RO config for SSTU, we already have a working SLS (Block I, Block II and MPCV) in the RO github repo, and thanks to Shadowmage who did the orange cryo texture the folks that want orange SLS can be happy, as well as those who want a white and black one:

http://imgur.com/a/jLLmA

btw, it's still a WIP, not all parts are supported yet, like the lander parts, and changes can and will happen, and ANY RO related issue should be reported in the RO thread, not here

EDIT: Shadowmage, got one idea for the SRBs, since the nosecones are there just for aerodynamics because KSP doesn't handle double staging, would it be possible to have a separate part for SRB separation? you could keep the current nosecones in the meses if one just wants them for aerodynamics, but add a new part with these nosecones having separatrons (tweakable for each SRB variant for the bottom ones) to be attached when you select the flat cap

the models and textures are already there, they would just need the separatrons to be added to them

Thanks a ton

I'm sure there are a few others who will express similar thanks. Have had lots of questions regarding RO configs, and now I have something to point them towards.

Will definitely be working with you more as I start getting the engine cluster stuff put together, and will likely try to help you develop configs/patches as the parts are developed.

Can give some thought to the nose-cone stuff; honestly though if I'm going to do a jettison motor type thing I'll likely combine it into a radial decoupler.

Gah...why can't KSP just 'fix' the staging stuff and allow one staging-icon/action-per-partModule rather than per-part (or remove the restrictions altogether)? Would make this entire thing so much easier to deal with, and many of my earlier designs would have actually worked.

Edited October 21, 2015 by Shadowmage

[davidy12]

YES! Finally I can make the SLS properly in RO.

[davidy12]

Have you thought about making the Dark Knight SRBs (Advanced SLS boosters)?

http://www.nasaspaceflight.com/2013/01/the-dark-knights-atks-advanced-booster-revealed-for-sls/

- - - Updated - - -

Also another thing the CSM shrinks to default size when I reset. (Quick save, revert to launch etc)

[riocrokite]

Have you thought about making the Dark Knight SRBs (Advanced SLS boosters)?

http://www.nasaspaceflight.com/2013/01/the-dark-knights-atks-advanced-booster-revealed-for-sls/

speaking of advanced boosters and stuff; what about SpaceX raptor engine? in stock KSP it could be positioned i.e. in 2.5m or 3.75m engines range with much more boost but less isp or other way round. So it could be used for example as a LFO booster engine for SLS block 2 / 2B (utilizing your resizable tanks):

[TABLE=class: infobox]

[TR]

[TH]Thrust (vac.)[/TH]

[TD]860 tf (8,400 kilonewtons)[/TD]

[/TR]

[TR]

[TH]Thrust (SL)[/TH]

[TD]720 tf (7,050 kilonewtons)[/TD]

[/TR]

[/TABLE]

[blowfish]

My choices are either plugin-based cluster manipulation with stats loaded from config; or making 20(engines) * 6 (stack sizes) * 9 (cluster variants) different engine parts (1080 parts, less as not all are available in all combos, but still many hundreds). I don't think anyone wants that kind of editor bloat, and I don't want to make that many different parts. Not when I can get it down to 6 editor parts.

It is a known caveat that there might be mods it will not play nicely with 'out of the box'. As with RF/RO/etc, I might need to do some compat patching on my end. However, as with the fuel tanks, it will all be config based, so most anything should be changeable through simple MM patch. Honestly though, the ability to use engine clusters for me far outweighs any incompatibility problems. Many ideas I cannot realize in-game due to KSPs part-count limitations; and removing that restriction from the engines/clusters would be simply awesome.

I think hundreds might still be an overestimate, but point taken

I'm curious how you're going to implement this though ... presumably by having multiple engine modules and enabling/disabling them?

I was not able to find any concrete data on the Merlins; especially there was a lack of diagrams and bell diameter information. However, I rough-guessed about where they would be based on the stats I did have, and have added 6 different Merlin variants to the list (B / B-vacuum, C / C-vaccum, D / D-vacuum) (they might not even really exist in those combinations...but w/e).

There seem to be enough stats on the wikipedia page to infer most of the thrust/Isp stats for the C/D variants. Let me know if you want any help determining them.

Nozzle area is a bit harder, but the diagram riocrokite showed might help (and here is a larger SVG version). Not sure what variant it's for though. You can also use the formula ThrustVac-ThrustSL = NozzleArea * PressureSL. Using this I get a diameter of 0.868m for the 1C and 0.938m for the 1D (note that this is internal diameter)

But this assumes no flow separation, so it wouldn't work for the vacuum variants (which don't have known SL stats anyway). Pixel measurements of this image could give the diameter approximately (I can do that later if you want).

Finally, I'd say don't worry about creating too many variants of the same engine. All of the merlin variants are very similar in terms of performance, and there's probably not a reason to use older ones when newer ones are available. I'd be happy with just the 1D and 1D vacuum

- - - Updated - - -

http://www.nasaspaceflight.com/wp-content/uploads/2014/03/Z91.jpg

Are you sure that's the Raptor? It looks like a gas generator engine to me.

[Shadowmage]

I think hundreds might still be an overestimate, but point taken

I'm curious how you're going to implement this though ... presumably by having multiple engine modules and enabling/disabling them?

There seem to be enough stats on the wikipedia page to infer most of the thrust/Isp stats for the C/D variants. Let me know if you want any help determining them.

Nozzle area is a bit harder, but the diagram riocrokite showed might help (and here is a larger SVG version). Not sure what variant it's for though. You can also use the formula ThrustVac-ThrustSL = NozzleArea * PressureSL. Using this I get a diameter of 0.868m for the 1C and 0.938m for the 1D (note that this is internal diameter)

But this assumes no flow separation, so it wouldn't work for the vacuum variants (which don't have known SL stats anyway). Pixel measurements of this image could give the diameter approximately (I can do that later if you want).

Finally, I'd say don't worry about creating too many variants of the same engine. All of the merlin variants are very similar in terms of performance, and there's probably not a reason to use older ones when newer ones are available. I'd be happy with just the 1D and 1D vacuum

The part is only going to have a single ModuleEngines/ModuleEnginesFX (likely the latter). There will be a second module (SSTUCustomEngineCluster) that will be responsible for all mesh-switching, recreating thrust transforms in the proper place, and doing run-time altering of the engine stats to match those of the selected engine and cluster setup.

Generally I've found that enabling/disabling multiple modules on the same part does not work out well, especially in regards to compatibility; MJ/etc don't check to see if a module is disabled, and count it as an engine/decoupler/whatever regardless.

I'm actually working through the engine mount/variant count at the moment. So far I have 120 distinct mounts (and that is without counting any over-sized mounts; e.g. SLS/SaturnV/Pyrios). Multiply that by the engines usable for each mount size (generally 4 per mount size), and you still have ~480 distinct part variants (can minus some for the non-existent 0.375m, 2.625, 3m engines, but then add nearly the same amount for the oversized/lower stage mounting options). Will likely have a final count later today... but yes, it is definitely going to be multiple hundreds of distinct variants.

Yes, this is going to take me awhile to put together; just the geometry for the mounts will likely take a few days/weeks to put together (thats ... alot ... of mounts). Granted, some will just be rescales (38/120 are rescales currently), but is still a ton of parts to put together.

[blowfish]

Generally I've found that enabling/disabling multiple modules on the same part does not work out well, especially in regards to compatibility; MJ/etc don't check to see if a module is disabled, and count it as an engine/decoupler/whatever regardless.

It works for engines - it has to, because of MultiModeEngine (which I think controls enabled and isEnabled). But if you're going the single module route, you might want to have a look at ModuleEngineConfigs in RF - that should already do most of what you want to accomplish, minus the mesh switching.

[Shadowmage]

It works for engines - it has to, because of MultiModeEngine (which I think controls enabled and isEnabled). But if you're going the single module route, you might want to have a look at ModuleEngineConfigs in RF - that should already do most of what you want to accomplish, minus the mesh switching.

MultiModeEngine is a separate module entirely (it is not an engine module, merely interacts with/controls the engine modules) and you may only have one MultiModeEngine on a part (or rather, multiples will not interact properly; each controls a distinct set of engines, with no opportunity for chaining). MJ/KER etc check for this module explicitly to see which engine stats they should use. Without MultiModeEngine module, multiple engine modules do not work properly (e.g. the SC-B-SM gives improper thrust and dV values if you disable one of its engines). And there is no way to get a single MultiModeEngine module to support the many different engine configs that I will be needing.

Will investigate the RF module though; didn't think that I noticed any custom engine modules when I was looking through the repo last week, but granted I was looking for fuel tank stuff rather than engines.

Sadly, I'm still stuck using either ModuleEngines or ModuleEnginesFX (or a custom derived class from one or the other), due to lack of support of non-derived engine module classes in MJ/etc. Example: At one point I did write an entirely custom engine module, that solved many of the performance problems and quirks in the stock engine module; sadly, MJ/etc would not recognize it because they are hard-coded to only support engine modules that derive from the stock classes; would need a common API/stock support with a generic IEngineModule interface or some such to make things work cleanly).

That said, if I do write up a custom engine module I could certainly look to implement some details from the RF engine module; will know more after I start working on the coding side of this project.

Edit: -- Just found an additional reduction technique I can employ for the engine mounts to cut down on the number of models that I need to create. It won't effect the end-results / number of variants, except for some variants/cluster setups you may use a smaller tank mount than the tank you are mounting it on.

For example, there is no need for a 3x 1.5m mount for 5m tanks, as there will be a 3x 1.5m mount for 3.75m tanks that could be mounted on a 5m-3.75m tank adapter (which, as they are included in the tanks, is zero extra parts). But there will be a 4x 1.5m and 5x 1.5m mount for 5m tanks as those variants are not available in smaller sizes.

Still working on figuring out all the mount variants I need to come up with. Should have a final # by the end of the day.

Edited October 21, 2015 by Shadowmage

[blowfish]

MultiModeEngine is a separate module entirely (it is not an engine module, merely interacts with/controls the engine modules) and you may only have one MultiModeEngine on a part (or rather, multiples will not interact properly; each controls a distinct set of engines, with no opportunity for chaining). MJ/KER etc check for this module explicitly to see which engine stats they should use. Without MultiModeEngine module, multiple engine modules do not work properly (e.g. the SC-B-SM gives improper thrust and dV values if you disable one of its engines). And there is no way to get a single MultiModeEngine module to support the many different engine configs that I will be needing.

I know that it's not an engine module - I was suggesting to write something like it. But you're right that MJ/KER look at MultiModeEngine specifically - that part I missed.

Will investigate the RF module though; didn't think that I noticed any custom engine modules when I was looking through the repo last week, but granted I was looking for fuel tank stuff rather than engines.

It's not an engine module. It's a separate module that modifies the stats of the engine module.

Sadly, I'm still stuck using either ModuleEngines or ModuleEnginesFX (or a custom derived class from one or the other), due to lack of support of non-derived engine module classes in MJ/etc. Example: At one point I did write an entirely custom engine module, that solved many of the performance problems and quirks in the stock engine module; sadly, MJ/etc would not recognize it because they are hard-coded to only support engine modules that derive from the stock classes; would need a common API/stock support with a generic IEngineModule interface or some such to make things work cleanly).

That said, if I do write up a custom engine module I could certainly look to implement some details from the RF engine module; will know more after I start working on the coding side of this project.

ModuleEnginesFX now derives from ModuleEngines, and all custom modules should derive from one of them. Not sure about KER, but MJ will definitely pick up subclasses properly.

If you look at RF's engine module (ModuleEnginesRF), you will see that it derives from ModuleEnginesSolver (which derives from ModuleEnginesFX). ModuleEnginesSolver is provided by SolverEngines and provides a paradigm for custom performance calculations. Just a heads up.

[JoseEduardo]

here's an RO example, the J-2 from FASA: https://github.com/FFCJoseEduardo/RealismOverhaul/blob/5cd525f8cb0aa1d2d1aa4af414d35fc906a14b77/GameData/RealismOverhaul/RO_SuggestedMods/FASA/RO_FASA_Saturn.cfg#L798-L950

it uses the default moduleenginesfx as default setting, but has a new module that allows for changing many aspects from the engines such as isp, thrust, fuel ratio, heat, and some that aren't even from the engine, like cost

[Shadowmage]

ModuleEnginesFX now derives from ModuleEngines, and all custom modules should derive from one of them. Not sure about KER, but MJ will definitely pick up subclasses properly.

If you look at RF's engine module (ModuleEnginesRF), you will see that it derives from ModuleEnginesSolver (which derives from ModuleEnginesFX). ModuleEnginesSolver is provided by SolverEngines and provides a paradigm for custom performance calculations. Just a heads up.

And therein lies the problem. You cannot do a clean engine implementation while deriving the class from the stock ModuleEngines (you are stuck with all of the stock garbage that way). Yes, MJ/etc pick up subclasses of ModuleEngines properly; my problem is that they do not pick up clean (non-derived) base classes, regardless of interface used (e.g. there is a IThrustProvider interface in stock, but MJ/etc do not use it for determining what module is an engine).

Anyway, I've moved past the whole unable-to-use-custom-engine-class problem, and have settled on using the stock engine modules with all their quirks and inefficiencies. Now I just need to find the best way to manipulate it to make it work with my intended setup (as far as I know it is all doable; all the fields I need to manipulate in the engine module are public / visible / readily alterable). The biggest bit that I haven't worked out yet is the run-time population of the FX for the different engines.

Hmm... will def. look into the RF EnginesConfig module, if nothing else than as to references as to how they are manipulating stats/etc. And solver engines; I've heard the name tossed around a ton (especially in regards to RO), but have never investigated them/looked at it. Will do that before I start doing the coding end of things. Might not have to completely re-invent the wheel, as it where.

Did quite a bit of trimming to the engine mounts list, using smaller sized mounts where possible (e.g. not creating the bigger one if a smaller size with the same engines exists), and I'm down to 35 distinct models that I need to make (not including the oversized mounts... still undecided as to the best way to do those/what sizes).

[JoseEduardo]

Do you plan to build every engine mesh config or something like the nosecones and endcaps? personally something like the nosecones/endcaps where you stick the mount and then select which engine and how many would be awesome, and you wouldn't have to make every variable mesh, just have them configured via a plugin, like Procedural Parts does with the thrust plate and procedural fairings with fairing and interstage base, except that they add nodes, not whole engines

EDIT: BTW, will you make just upper stage mounts or lower stage mounts too?

here's why I'm asking:

http://www.astronautix.com/lvs/satrnc3b.htm

http://www.astronautix.com/lvs/saturnc4.htm

http://www.astronautix.com/lvs/satrnc4b.htm

and because of the Jupiters I showed before

btw, as it appears from the drawings the C-3B would have 3 inline F-1 and two aerodynamic covers (even though the inclined one shows 4), resembling the Jupiter from DIRECT V2 with 3x RS-68

C-4B looks like a reguar Saturn V F-1 mount, but without the center engine

Edited October 21, 2015 by JoseEduardo

[Shadowmage]

Do you plan to build every engine mesh config or something like the nosecones and endcaps? personally something like the nosecones/endcaps where you stick the mount and then select which engine and how many would be awesome, and you wouldn't have to make every variable mesh, just have them configured via a plugin, like Procedural Parts does with the thrust plate and procedural fairings with fairing and interstage base, except that they add nodes, not whole engines

Will be using mesh-variant setups like the nose-cones. Basically it will be the thrust-plates from PP, but with engines integrated all into a single part, with hand-built models for everything.

There will be one part in the editor per stack size (0.625m, 1.25m, 1.875m, 2.5m, 3.75m). You will slap this onto your rocket in its intended position/orientation. From there you will pick the engine type and clustering configuration through right-click menus (or other GUI selection in the future).

I would love to do completely custom models per-engine-per-cluster-per-stack size; but ugh... that is far too many models and textures to manage. It is already going to be a handful as it is.

After 1.1 is release I will likely revisit the GUI and parts layout to combine them -all- into a single part where you add it to the ship and right-click to configure everything (stack size, engine type, cluster layout). Would need a more complex GUI than I can currently do using stock right-click mechanics, so this will have to wait until the GUI updates. (Yes, I know, it -is- possible to do custom GUI's right now, such as Real-Fuels fuel selection GUI, but I'm holding off on doing any GUI work until Squad has a unified system in place).

- - - Updated - - -

Nozzle area is a bit harder, but the diagram riocrokite showed might help (and here is a larger SVG version). Not sure what variant it's for though. You can also use the formula ThrustVac-ThrustSL = NozzleArea * PressureSL. Using this I get a diameter of 0.868m for the 1C and 0.938m for the 1D (note that this is internal diameter)

But this assumes no flow separation, so it wouldn't work for the vacuum variants (which don't have known SL stats anyway). Pixel measurements of this image could give the diameter approximately (I can do that later if you want).

Finally, I'd say don't worry about creating too many variants of the same engine. All of the merlin variants are very similar in terms of performance, and there's probably not a reason to use older ones when newer ones are available. I'd be happy with just the 1D and 1D vacuum

Ooh.. new math to learn

I might have the diameters off a bit currently if what you've calculated is close to accurate; I only found one mention of diameter (1.25m) but it did not specify which variant, and with such an even/round number it looked a bit suspect (usually it would be like 1235mm or something). The walls of the bell usually only appear to be ~1.5cm thick for most engines that I've examined, so the outer diameter would likely not be too much greater than what you have listed.

I've included multiple variants of some of the engines as I intend some of those variants to become unlocked earlier in career-mode games. Yes, some will likely become obsoleted later in the game by other variants/other engines. Some may have specific characteristics that still make them desirable late-game. Also, variants are fairly easy to create as they generally will share a lot of geometry (and possibly texture). Still working through the whole thing though, so I'm open to suggestions. Certainly some of the variant stuff will come later. The initial selection might only be 8-10 engines, though I've tried to get a decent assortment put together for various purposes.

- - - Updated - - -

EDIT: BTW, will you make just upper stage mounts or lower stage mounts too?

here's why I'm asking:

http://www.astronautix.com/lvs/satrnc3b.htm

http://www.astronautix.com/lvs/saturnc4.htm

http://www.astronautix.com/lvs/satrnc4b.htm

and because of the Jupiters I showed before

btw, as it appears from the drawings the C-3B would have 3 inline F-1 and two aerodynamic covers (even though the inclined one shows 4), resembling the Jupiter from DIRECT V2 with 3x RS-68

C-4B looks like a reguar Saturn V F-1 mount, but without the center engine

I intend on making several shrouded/shielded mounts as well, where mostly just the bell is sticking out. And yes, some will be 'oversized' similar to the Saturn and SLS core stages where the engines protrude out the side a bit. Some engines will even have specific covers for that engine in some setups; such as the RS-68 (pretty much requires a custom shroud with those big arms/exhaust ducts sticking out). I even intend on providing several aesthetic-only layout options for some cluster configurations (such as 5 engines in a ring, 5 engines in a cross, or 5 engines in a flattened cross (SLS)). Some of those aesthetic variants might not be available initially, but if I do the coding right they will be easy enough to add in later.

[blowfish]

1.25m sounds suspect to me. I believe the entire Falcon rocket is 3.7m, so if the engines were 1.25m then there's no way you could fit 9 of them.

[JoseEduardo]

hype is real, after these engine clusters are finished I guess the only parts from KW that I will still use are going to be the adapters (the dark gray and green ones) and the payload bases

that is, if you doesn't decide to make them too lol

[stratochief66]

Have you thought about making the Dark Knight SRBs (Advanced SLS boosters)?

http://www.nasaspaceflight.com/2013/01/the-dark-knights-atks-advanced-booster-revealed-for-sls/

- - - Updated - - -

Also another thing the CSM shrinks to default size when I reset. (Quick save, revert to launch etc)

That is the WIP kicking in. Basic scaling (as it is now): relatively easy. To get it to not do that, we need to rescale the position of all of the nodes manually, because base KSP is fun like that. That takes much more work, and comes later. You can come to the RO IRC and we can talk you through helping out with that if you like.

- - - Updated - - -

About RO... Are you guys going to add real plume soon?

I got those done! They can probably do with some tweaks (all RealPlumes can, they are art!) but I am relatively happy with them. Working RO configs with no plumes was a bit sad sometimes.

- - - Updated - - -

Great to hear!!! Can't wait to see the plumes hope they come soon

On a side note, the CSM of the Orion is about 1100 m/s. So I'd go with that.

PS: Another thing that has been bothering me, the bottom engines (4 thrusters around the SPS) are supposed to be high powered RCS thrusters not actual engines.

- - - Updated - - -

Also the core stage for RO has only 220 m/s of DV when stretched to realistic length.

- - - Updated - - -

Also, you need to look at the nodes for RO. (Decoupler)

Jose is taking care of RO'ing the tank stuff (and he did quite well!) as I was just expecting to use ProcTanks since they are infinitely modifiable. However, I think Jose got the tanks to function alright, last time I checked them they were a bit underweight and I don't know if he had a way forward with that.

[riocrokite]

Shadowmage, was just thinking about trade-offs between sticking to ModuleEngine stock module vs developing your custom one.

Maybe an option would be to just go your own way and implement your own module for engines (since you write it solves some problems and that would be good for performance optimization).

I'm quite sure that sooner or later Mechjeb/KER developers would take your new plugin into their calculations so their mods would work correctly with your engine clusters. If not I'm quite sure that people would write addons to those (for example new categories in KER > cluster dV/TWR/thrust) so they show correct numbers. I also wouldn't worry about other people writing custom MM configs since those could also be modified to be correct with a custom engine module.

@blowfish

About that raptor engine, this pic shows Merlin 2 engine concept (supposedly), a predecessor to raptor (since raptor itself hasn't been revealed yet)

http://spaceflight101.com/spacex-launch-vehicle-concepts-designs/

some more stats:

Interestingly Russians are developing their own versions of Raptor methalox engines with similar stats (RD-0162 and RD-0164):

http://forum.nasaspaceflight.com/index.php?topic=33645.0

They intend to use them for new Soyuz 5 launch vehicles:

http://www.russianspaceweb.com/soyuz5.html

LEFT: RD-0162, 2032 kN SL thrust, weight = 2.1t, height: 3.5m, diameter(max): 1.65m, isp:321-356

RIGHT: RD-0164, 2800-3000 kN thrust - single engine per column

---

Meanwhile here are some pictures that might help with modelling Merlin engine (by Brain Haeger; www.bionic3d.com ):

Edited October 22, 2015 by riocrokite

[JoseEduardo]

Jose is taking care of RO'ing the tank stuff (and he did quite well!) as I was just expecting to use ProcTanks since they are infinitely modifiable. However, I think Jose got the tanks to function alright, last time I checked them they were a bit underweight and I don't know if he had a way forward with that.

the tanks have been fixed since he posted that

[Shadowmage]

1.25m sounds suspect to me. I believe the entire Falcon rocket is 3.7m, so if the engines were 1.25m then there's no way you could fit 9 of them.

Suppose its a good thing I haven't started modeling those engines yet Will certainly have to settle on some specific diameters and setups before I start working on them in earnest.

hype is real, after these engine clusters are finished I guess the only parts from KW that I will still use are going to be the adapters (the dark gray and green ones) and the payload bases

that is, if you doesn't decide to make them too lol

Payload fairings - planned at some point. They will be one of the last pieces needed to fill out the 'Ship Core' A/B set of parts.

Adapters - mostly available already as nosecone options on the fuel-tanks. Will consider making some of them as stand-alone parts if there is enough demand/need (models and textures already exist, would just be creating the part.cfg file for it and setting up positions/nodes for the model correctly).

That is the WIP kicking in. Basic scaling (as it is now): relatively easy. To get it to not do that, we need to rescale the position of all of the nodes manually, because base KSP is fun like that. That takes much more work, and comes later. You can come to the RO IRC and we can talk you through helping out with that if you like.

- - - Updated - - -

I got those done! They can probably do with some tweaks (all RealPlumes can, they are art!) but I am relatively happy with them. Working RO configs with no plumes was a bit sad sometimes.

- - - Updated - - -

Jose is taking care of RO'ing the tank stuff (and he did quite well!) as I was just expecting to use ProcTanks since they are infinitely modifiable. However, I think Jose got the tanks to function alright, last time I checked them they were a bit underweight and I don't know if he had a way forward with that.

Gotta love the funky scaling stuff that stock does Glad you got it figured out though.

With all the work you guys are putting in for RO, I'll probably be giving it a try for my next new game that I start (if I can get it all working properly in career mode).

Yah, playing with effects is definitely more of an art; always room for 'improvement' (for various definitions of the word).

Shadowmage, was just thinking about trade-offs between sticking to ModuleEngine stock module vs developing your custom one.

Maybe an option would be to just go your own way and implement your own module for engines (since you write it solves some problems and that would be good for performance optimization).

I'm quite sure that sooner or later Mechjeb/KER developers would take your new plugin into their calculations so their mods would work correctly with your engine clusters. If not I'm quite sure that people would write addons to those (for example new categories in KER > cluster dV/TWR/thrust) so they show correct numbers. I also wouldn't worry about other people writing custom MM configs since those could also be modified to be correct with a custom engine module.

@blowfish

About that raptor engine, this pic shows Merlin 2 engine concept (supposedly), a predecessor to raptor (since raptor itself hasn't been revealed yet)

http://spaceflight101.com/spacex-launch-vehicle-concepts-designs/

some more stats:

http://104.131.251.97/wp-content/uploads/2015/09/SpaceX-Concept.jpghttp://104.131.251.97/wp-content/uploads/2015/09/Raptor.jpg

Interestingly Russians are developing their own versions of Raptor methalox engines with similar stats (RD-0162 and RD-0164):

http://forum.nasaspaceflight.com/index.php?topic=33645.0

They intend to use them for new Soyuz 5 launch vehicles:

http://www.russianspaceweb.com/soyuz5.html

LEFT: RD-0162, 2032 kN SL thrust, weight = 2.1t, height: 3.5m, diameter(max): 1.65m, isp:321-356

RIGHT: RD-0164, 2800-3000 kN thrust - single engine per column

http://www.kbkha.ru/upload/kpo/581650053.jpghttp://www.russianspaceweb.com/images/rockets/soyuz/soyuz5/soyuz5_lebourget_2013_side_2.jpg

---

Meanwhile here are some pictures that might help with modelling Merlin engine (by Brain Haeger; www.bionic3d.com ):

http://41.media.tumblr.com/475967aac187835776ff340285765e2e/tumblr_mh3evvJ2Tg1r01w8mo1_1280.jpg

http://www.bionic3d.com/style/images/portfolio/merlin-spacex-rocket-motor.jpg

http://www.bionic3d.com/style/images/portfolio/merlin-spacex-illustration-2.jpg

Awesome, thanks for the pics and data. Will see about merging this stuff into my existing data sheets and picture stores.

WRT to custom engine module; I might be contacting Sarbian shortly to figure out the best way to set this up. It seems like I'm not the only mod that could benefit from custom engine modules with full MJ support, but I'm unsure as to the proper method to setup such compatibility through c# while maintaining stand-alone capability (with Java you would use byte-code manipulation to strip interface defs from the class when the interface-base-class was not present). Ideally stock would add such an interface and all other mods would be able to use it for their custom engine implementations; though I highly doubt I will be able to get Squad devs to listen to my requests.

General Progress Update:

Running into some rather large issues with regards to rescaling; more specifically, allowing the custom engine clusters to cleanly be rescaled for use in RO/RSS/whatever and how it relates to the manually built models that I currently intend to use.

Engines are all modeled at 64% of real scale. Would be easy enough to rescale the engine models themselves back to realistic sizes. The problem comes from the hand-crafted mounts for stock stack-sizes; these do not cleanly rescale to RSS sizes using the standard 1.5625 '100% correction' rescale (e.g. 64% * 1.5625 = 100%). This results in strange/odd tank sizes (6.25m rescales to ~9.74m rather than the 10m it should, 5m = 7.8125 rather than 8.4m). If you rescale the mount to match the exact size needed all of the engines will need to be rescaled with it as well; resulting in different stack-sizes having different scaled engine models. Not good for a realism-based mod.

1.) The first alternative that I've thought up is to use consistent scaling for the engine mounts (e.g. 1.5625 scale), but allow specification of the interstage fairings to be whatever size is needed for that stack size. So, while the mount itself might be slightly smaller than the tanks, the engines would all be at proper scale. This seems like it -might- be the most workable solution; the aesthetics would be slightly off as the mounts/fuel lines would not match the tanks, but it should work.

2.) A second alternative that I'm heavily considering at this point is fully-procedural mounts rather than hand-built models. The problem that is ran into here is how to do this while still making them look good? Not sure that I could pull it off (without years of coding on it). A big problem with this is how to handle the special-case oversized mounts.

3.) A third alternative that I'm considering is somehow splitting up the mount model into multiple independently scalable parts. So you could maintain the motors at a standard rescale factor (1.5625x) but scale the stack-mounting plates by a different amount to make them cleanly line up with the stack size they are mounted on. This would also -greatly- cut down on the number of specific models that I need to create.

And just to throw a wrench in the gears there is the case of the special 'oversized' engine mounts and how to cleanly rescale those to be usable with random rescaling (can't see how it would be possible).

Perhaps I am getting a bit too ambitious with my plans and might need to scale this project back a bit. Even as it is (if I ignore the RSS rescale problems) the full set of parts will be 20 engine models, 51+ mounts, and 51+ mount shrouds. Of course this was with attempting to do very-detailed skeletal type mounts where all the fuel-lines match up and are routed properly. Might just rethink the mounting layout along the lines of #3 where there is a single tank-cap model that can be freely rescaled, and a single skeletal adapter per cluster layout that is rescaled appropriately for the motor mount size. Still has problems related to external shrouds (specifically the oversized/special ones).

Strangely the plugin-end of things I think will be the easier bit to figure out this time. Setup thrust transforms per engine type: check, simple enough to do. Alter engine module stats for selected engine (thrust/isp/mass/heat): very doable. Position engine models where needed based on cluster layout: no problem. Re-setup engine gimbal properly for engine type: simple. Re-setup engine FX properly for engine type: Not yet figured out, but preliminary investigation points out that it is doable.

Rescaling of models for use in RSS: No clue where to start.

Hmm... still quite a bit of figuring out to do on this stuff.

Will look at doing some mock-ups of engine mount stuff a bit later to see if I can figure out an easily freely-rescalable solution.